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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

Hi Jean,

Today's linux-next merge of the i2c tree got a conflict in
arch/arm/configs/kirkwood_defconfig arch/arm/configs/mv78xx0_defconfig
arch/arm/configs/orion5x_defconfig between various commits from the
arm-current tree and commit c637675d24618d8e0afe344096a1ad96986c4f50
("i2c/chips: Move max6875 to drivers/misc/eeprom") from the i2c tree.

The latter patch changes many defconfig files. Please don't do that -
especially for those defconfigs that do not select the config options you
are changing (which is the vast majority).  This just creates conflicts
for no purpose at all.  It looks like the only defconfigs that may have
needed updating are:

arch/mips/configs/bigsur_defconfig
arch/mips/configs/mtx1_defconfig
arch/powerpc/configs/ppc6xx_defconfig

I have dropped the changes to all the others (165 of them).  Please
update the patch.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

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

[Russell King]

On Wed, May 06, 2009 at 01:10:31PM +1000, Stephen Rothwell wrote:
> Hi Jean,
> 
> Today's linux-next merge of the i2c tree got a conflict in
> arch/arm/configs/kirkwood_defconfig arch/arm/configs/mv78xx0_defconfig
> arch/arm/configs/orion5x_defconfig between various commits from the
> arm-current tree and commit c637675d24618d8e0afe344096a1ad96986c4f50
> ("i2c/chips: Move max6875 to drivers/misc/eeprom") from the i2c tree.

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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

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

[Jean Delvare]

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.

-- 
Jean Delvare

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

[Jean Delvare]

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.

-- 
Jean Delvare

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

[Jean Delvare]

Hi Stephen,

On Wed, 6 May 2009 13:10:31 +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the i2c tree got a conflict in
> arch/arm/configs/kirkwood_defconfig arch/arm/configs/mv78xx0_defconfig
> arch/arm/configs/orion5x_defconfig between various commits from the
> arm-current tree and commit c637675d24618d8e0afe344096a1ad96986c4f50
> ("i2c/chips: Move max6875 to drivers/misc/eeprom") from the i2c tree.
> 
> The latter patch changes many defconfig files. Please don't do that -
> especially for those defconfigs that do not select the config options you
> are changing (which is the vast majority).  This just creates conflicts
> for no purpose at all.

I don't know exactly how defconfigs are handled, but I can imagine that
the responsible developer is running "make oldconfig" on the system in
question from times to times and copying the result back to the
defconfig file. The purpose of updating defconfig files is to make
configuration option renames transparent.

I can't see why defconfigs which select the option on question are
different from defconfigs not selecting it in this respect. In both
cases, if we don't update the file, a subsequent "make oldconfig" will
ask about the "new" option.

Or is there a specific procedure to update defconfig files which
answers "no" to all questions by default?

> It looks like the only defconfigs that may have needed updating are:
> 
> arch/mips/configs/bigsur_defconfig
> arch/mips/configs/mtx1_defconfig
> arch/powerpc/configs/ppc6xx_defconfig
> 
> I have dropped the changes to all the others (165 of them).  Please
> update the patch.

I have done so, sorry for the trouble.

-- 
Jean Delvare

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

[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:

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

[Russell King]

On Wed, May 06, 2009 at 10:31:38AM +0200, Jean Delvare wrote:
> I don't know exactly how defconfigs are handled, but I can imagine that
> the responsible developer is running "make oldconfig" on the system in
> question from times to times and copying the result back to the
> defconfig file. The purpose of updating defconfig files is to make
> configuration option renames transparent.

The big problem is that everyone 'make oldconfig' is done, the entire
config file essentially gets re-sorted into some other random order,
and the changes are massive.

If a platform maintainer does this, and the result is committed, and
some other person has done some small sed-based updates to the defconfigs,
the result is _total_ chaos.

That's why I'm arguing for my approach.  That way, platform maintainers
stand a better chance of seeing what happens to their defconfig files
and there's a substantially better chance of some coordination of those
changes (that is if the arch maintainer is doing their job properly.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

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

[Jean Delvare]

Hi Russell,

On Wed, 6 May 2009 20:01:10 +0100, Russell King wrote:
> On Wed, May 06, 2009 at 09:25:59AM +0200, Jean Delvare wrote:
> > 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.

Thanks for the explanation, I understand your point. I was updating the
defconfigs to make the maintainer's lives easier. If this has the
opposite effect, I'll just stop doing it, that's less work for me.

-- 
Jean Delvare

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

[Jean Delvare]

Hi Russell,

On Wed, 6 May 2009 20:01:10 +0100, Russell King wrote:
> On Wed, May 06, 2009 at 09:25:59AM +0200, Jean Delvare wrote:
> > 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.

Thanks for the explanation, I understand your point. I was updating the
defconfigs to make the maintainer's lives easier. If this has the
opposite effect, I'll just stop doing it, that's less work for me.

-- 
Jean Delvare