> However providing you separate the initial profile from the later tools
> it simply becomes
> make distroconfig
> [cp /etc/system-kconfig(.$ARCH?) .config
> make oldconfig]
> make menuconfig (if you want to customise)
the effort will be around creating the distro specific options.
If the solution ends up being miniconfig like, then the distros produce snippets of .config that contain their requirements
If the solution is additional selection items in the kconfig system, then the distros will need to produce the appropriate kconfig code to select the right things.
In either case, the hardest work is going to be figuring out what the correct options should be.
the biggest reason I would prefer to see the miniconfig approach is that it allows each distro to provide the appropriate file as part of the distro update process.
This avoids the risk of a huge amount of distro specific code in the kernel.org tree. And the political questions like how big does a distro need to be to get it's config included in kernel.org, how long after release does it remain there. There are hundreds of distros out there and at the other extreme a single Debian release can produce 30-40 different kernel configs (although defining 'minimum' tightly enough can reduce this).
Linus complained a few years ago about the horrible defconfig churn, putting the per distro, per release info in the kernel config seems like it is begging for the same sorts of problem.
There will also be a gap between the time the distro releases a version and when the minimum config for that version can get into the kernel.org tree. You will have a ~3-5 month lag between the time the distro defines a minimum and when a kernel release comes out that includes it. As a result, the first kernel.org kernel that will have the 'proper' minimum config for a distro will be at least two revisions newer than the version the distro ships.
However, I'm not a kernel developer, I'm 'just' a sysadmin who's been using linux since the 0.99 days My contribution consists of testing and feedback, so while I can warn of problems that I see with an approach, and try to convince others. Ultimately this is going to be up to the distro maintainers to decide which approach they are going to be willing to implement.