Heads up: Linus plans to kill ARM defconfigs

[Tony Lindgren]

* Russell King - ARM Linux <linux at arm.linux.org.uk> [100608 14:53]:
> On Fri, Jun 04, 2010 at 04:51:24PM -0400, Nicolas Pitre wrote:
> > Linus wants something to be done about the current defconfig mess which 
> > is perfectly legitimate.  He even suggested a possible solution.  I 
> > don't think he'll simply drop those defconfig files if we demonstrate 
> > that we're taking action to fix the actual problem.
> 
> However, having a set of patches which combine a load of defconfig
> files into one is not going to solve the problem.
> 
> If you're hypothesis that Linus is only looking at the diffstat, then
> what are patches to combine the defconfigs going to do?  It's going
> to create lots of noise in arch/arm/configs/ - which is precisely what
> Linus is complaining about.  In fact, patch-wise it's going to create
> an extremely large patch.  And if we do this time and time again while
> progressively reducing the defconfigs.  No, this isn't the answer -
> it's only going to make the problem worse.
> 
> I believe the only acceptable solution is to get an alterative method
> in place - no matter what it is - and remove the all but one of the
> defconfig files from the mainline kernel.  _And_, most importantly,
> kautobuild needs to be fixed so that we still get build coverage.
> 
> The loss of kautobuild is a major concern here, and I believe it trumps
> everything else for the next merge window.  Kautobuild is an extremely
> important resource that we simply can not afford to lose.

How about the following strategy for the next merge window:

- Update kautobuild to temporarily host the current defconfigs

- Remove all the arm defconfigs except one

Then over the next few merge cycles:

- Make the ARM platform specific Kconfig or similar option to work

- Drop the old defconfigs from kautobuild once we have the new solution

Then over yet unknown lenght of time:

- Work towards building in more features (TLS/SMP/VFPvX) into the same kernel

- Work towards building in multiple ARM platforms into the same kernel

Regards,

Tony