Re: linux-next: manual merge of the i2c tree with the arm-currenttree

[Russell King]

On Wed, May 06, 2009 at 09:25:59AM +0200, Jean Delvare wrote:
> Hi Russell,
> 
> On Wed, 6 May 2009 08:15:48 +0100, Russell King wrote:
> > Since defconfig updates are always going to create lots of noise, and
> > the files are normally out of date, the *only* sensible way to handle
> > updates is to have one tree dealing with them per architecture.
> > 
> > Spreading them across multiple trees and then expecting merges to sort
> > out the resulting mess is unreasonable; they just change far too much
> > when updates happen.  Moreover, defconfig updates should be in their
> > own separate commit and not combined with other changes.
> 
> I fail to see how you can handle configuration option renames
> gracefully with your proposed model.

That's not the point I'm making.  The point I'm making is about the
merge issues which is the BIG and I mean BIG as in 1000ft tall
letters BIG problem with scattering defconfig patches everywhere.

The reality of defconfigs is that they're normally months out of date
with respect to the current kernel, and are occasionally updated by
the platform maintainers on an occasional basis (as has happened with
Nicolas' change which your tree has clashed with.)

I've heard it argued that the only people who should ever touch defconfig
files are the platform maintainers themselves.  What I'm suggesting is
one step closer to sanity than that position - having the arch maintainer
responsible for dealing with all changes to those files, thereby providing
a centralised point for synchronising and co-ordinating all defconfig
updates.

If you think you have a better solution (no, throwing them into your own
I2C tree is NOT a solution - it's a cause of major problems) then please
state it.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/