From: Jean Delvare <khali@linux-fr.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: linux-next@vger.kernel.org, Nicolas Pitre <nico@cam.org>,
Wolfram Sang <w.sang@pengutronix.de>,
Russell King <rmk@arm.linux.org.uk>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: manual merge of the i2c tree with the arm-current tree
Date: Wed, 6 May 2009 10:31:38 +0200 [thread overview]
Message-ID: <20090506103138.79525cd0@hyperion.delvare> (raw)
In-Reply-To: <20090506131031.83f1b04d.sfr@canb.auug.org.au>
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
next prev parent reply other threads:[~2009-05-06 8:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-06 3:10 linux-next: manual merge of the i2c tree with the arm-current tree Stephen Rothwell
2009-05-06 7:15 ` Russell King
2009-05-06 7:25 ` Jean Delvare
2009-05-06 19:01 ` Russell King
2009-05-07 6:54 ` Jean Delvare
2009-05-06 8:31 ` Jean Delvare [this message]
2009-05-06 19:04 ` Russell King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090506103138.79525cd0@hyperion.delvare \
--to=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=nico@cam.org \
--cc=rmk@arm.linux.org.uk \
--cc=sfr@canb.auug.org.au \
--cc=w.sang@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox