From: Stephen Warren <firstname.lastname@example.org> To: Olof Johansson <email@example.com> Cc: Tony Prisk <firstname.lastname@example.org>, Stephen Warren <email@example.com>, Stephen Rothwell <firstname.lastname@example.org>, Colin Cross <email@example.com>, firstname.lastname@example.org, email@example.com, Arnd Bergmann <firstname.lastname@example.org>, email@example.com Subject: Re: linux-next: manual merge of the tegra tree with the arm-soc tree Date: Wed, 16 Jan 2013 10:08:45 -0700 Message-ID: <50F6DE9D.firstname.lastname@example.org> (raw) In-Reply-To: <CAOesGMgr_f-XGHOdMW3ugfXbVaUc4EALrbfJD=XeOKixxrY8PA@mail.gmail.com> On 01/16/2013 09:27 AM, Olof Johansson wrote: > Hi, > > On Tue, Jan 15, 2013 at 8:52 PM, Tony Prisk <email@example.com> wrote: >> On Tue, 2013-01-15 at 21:32 -0700, Stephen Warren wrote: >>> On 01/15/2013 08:49 PM, Tony Prisk wrote: >>>> On Wed, 2013-01-16 at 14:14 +1100, Stephen Rothwell wrote: >>>>> Hi all, >>>>> >>>>> Today's linux-next merge of the tegra tree got a conflict in >>>>> drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500: >>>>> Move timer code to drivers/clocksource") from the arm-soc tree and commit >>>>> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from >>>>> the tegra tree. >>>>> >>>>> I fixed it up (see below) and can carry the fix as necessary (no action >>>>> is required). >>>>> >>>> >>>> I don't know about everyone else, but I feel the preference should be to >>>> keep things alphabetized where possible to help avoid with merge >>>> conflicts later on. This is always a problem when we start tacking >>>> things on the end of lists. >>>> >>>> I realise this Kconfig is not alphabetized anyway, but it's never too >>>> early to start on the 'right' path. >>> >>> Sounds like a good idea, but the issue is: When to do the initial sort >>> so it doesn't conflict with all the adds in a kernel cycle... Post and >>> immediately commit a new patch near the end of the merge window? >> >> Given that the maintainer can quite safely do the patch (sorry >> maintainers), I don't see any reason why it couldn't be done at the >> point where they stop accepting patches for the merge-window. Once the >> patches are stopped, sort the list in one last patch. That only works well if the one maintainer is the only person taking patches for the drivers/clocksource tree. It might be true that the "one maintainer" here ends up being arm-soc in this kernel cycle though? >> It makes sense to get it done in this window if possible as the Kconfig >> will only get bigger as time goes on, making sorting it more time >> consuming. > > Actually, Russell wen through and reordered these not long ago, if I > remember correctly. The current ordering is the same as in the > structure definition, and should be kept that way. I think this is talking about Makefile entries rather than struct definitions?
next prev parent reply index Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-01-16 3:14 Stephen Rothwell 2013-01-16 3:49 ` Tony Prisk 2013-01-16 4:32 ` Stephen Warren 2013-01-16 4:52 ` Tony Prisk 2013-01-16 16:27 ` Olof Johansson 2013-01-16 17:08 ` Stephen Warren [this message] 2013-01-16 17:35 ` Olof Johansson -- strict thread matches above, loose matches on Subject: below -- 2020-03-26 22:27 Stephen Rothwell 2020-03-27 13:18 ` Thierry Reding 2020-03-27 13:50 ` Arnd Bergmann 2019-06-25 0:12 Stephen Rothwell 2015-12-02 11:46 Mark Brown 2013-03-18 4:31 Stephen Rothwell 2013-03-18 15:23 ` Stephen Warren 2013-03-18 15:49 ` Arnd Bergmann 2013-02-02 11:52 Stephen Rothwell 2013-02-02 11:45 Stephen Rothwell 2013-01-23 5:30 Stephen Rothwell 2013-01-23 5:25 Stephen Rothwell 2013-01-16 3:10 Stephen Rothwell 2013-01-16 3:12 ` Stephen Rothwell
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=50F6DE9D.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
Linux-Next Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \ email@example.com public-inbox-index linux-next Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next AGPL code for this site: git clone https://public-inbox.org/public-inbox.git