* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-18 23:09 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King, Stephen Rothwell, linux-next, lkml, Jeremy Kerr,
Jeff Ohlstein
In-Reply-To: <alpine.LFD.2.00.1010181833440.2764@xanadu.home>
On Mon, 2010-10-18 at 18:35 -0400, Nicolas Pitre wrote:
> > git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl | wc
> > 58 163 2169
> >
> > That's the patch we're actually discussing too. It's about one CC per
> > file modified.
>
> What is a mailing list for, then? Why are you subscribed?
I'm subscribes to review code .. Do you read every patch that cross the
arm list?
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Joe Perches @ 2010-10-18 22:53 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Daniel Walker, Russell King, Stephen Rothwell, linux-next, lkml,
Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <alpine.LFD.2.00.1010181833440.2764@xanadu.home>
On Mon, 2010-10-18 at 18:35 -0400, Nicolas Pitre wrote:
> On Mon, 18 Oct 2010, Daniel Walker wrote:
> > On Mon, 2010-10-18 at 22:58 +0100, Russell King wrote:
> > > On Mon, Oct 18, 2010 at 02:29:22PM -0700, Daniel Walker wrote:
> > > > That's why we have get_maintainer.pl, it adds in all the CC's
> > > > automatically ..
> > > $ git diff-tree -u 861bd81ee62a0d6759144c22909a8a3938951656 | scripts/get_maintainer.pl |wc
> > > 209 624 8021
> > > 209 recipients / 8K of To:/CC: is reasonable?
> > What it's showing you is anyone that's ever modified those files.. You
> > just need the people who maintain the files.
> > how about this,
> > git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl | wc
> > 58 163 2169
> > That's the patch we're actually discussing too. It's about one CC per
> > file modified.
> What is a mailing list for, then? Why are you subscribed?
> Please get real or get away.
Too true. The patch is entirely for arch/arm and
relatively few if any maintainers need to be cc'd.
This could have been done:
$ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
35
Even then, using 35 CCs is generally silly.
It _might_ make some sense for a cover letter and a
patch series where the series made tree-wide changes
in multiple directories.
Even so, lkml will sensibly reject emails with more
than a couple dozen CC's as likely spam.
For cover letters, I generally use:
./scripts/get_maintainer.pl --nom -l --nogit
and for each patch in a series
./scripts/get_maintainer.pl --no-git
There is a change in the get_maintainers.pl in Andrew
Morton's mm tree to default to --nogit.
The new get_maintainer.pl is available from:
git://repo.or.cz/linux-2.6/get_maintainer.git 20100922_gm
Have a look at:
http://repo.or.cz/w/linux-2.6/get_maintainer.git
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Nicolas Pitre @ 2010-10-18 22:35 UTC (permalink / raw)
To: Daniel Walker
Cc: Russell King, Stephen Rothwell, linux-next, lkml, Jeremy Kerr,
Jeff Ohlstein
In-Reply-To: <1287440826.5588.83.camel@c-dwalke-linux.qualcomm.com>
On Mon, 18 Oct 2010, Daniel Walker wrote:
> On Mon, 2010-10-18 at 22:58 +0100, Russell King wrote:
> > On Mon, Oct 18, 2010 at 02:29:22PM -0700, Daniel Walker wrote:
> > > That's why we have get_maintainer.pl, it adds in all the CC's
> > > automatically ..
> >
> > $ git diff-tree -u 861bd81ee62a0d6759144c22909a8a3938951656 | scripts/get_maintainer.pl |wc
> > 209 624 8021
> >
> > 209 recipients / 8K of To:/CC: is reasonable?
>
>
> The answer is not "The tool doesn't work like I want, so screw it." If
> the tool doesn't work like we want, then we need to fix the tool not
> just walk away. Not to mention that the people involved in making these
> patches should still be CC'ing people even if this tool is just helping
> them out instead of actually doing it for them.
>
> What it's showing you is anyone that's ever modified those files.. You
> just need the people who maintain the files.
>
> how about this,
>
> git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl | wc
> 58 163 2169
>
> That's the patch we're actually discussing too. It's about one CC per
> file modified.
What is a mailing list for, then? Why are you subscribed?
Please get real or get away.
Nicolas
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-18 22:27 UTC (permalink / raw)
To: Russell King
Cc: Nicolas Pitre, Stephen Rothwell, linux-next, linux-kernel,
Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <20101018215815.GC23642@flint.arm.linux.org.uk>
On Mon, 2010-10-18 at 22:58 +0100, Russell King wrote:
> On Mon, Oct 18, 2010 at 02:29:22PM -0700, Daniel Walker wrote:
> > That's why we have get_maintainer.pl, it adds in all the CC's
> > automatically ..
>
> $ git diff-tree -u 861bd81ee62a0d6759144c22909a8a3938951656 | scripts/get_maintainer.pl |wc
> 209 624 8021
>
> 209 recipients / 8K of To:/CC: is reasonable?
The answer is not "The tool doesn't work like I want, so screw it." If
the tool doesn't work like we want, then we need to fix the tool not
just walk away. Not to mention that the people involved in making these
patches should still be CC'ing people even if this tool is just helping
them out instead of actually doing it for them.
What it's showing you is anyone that's ever modified those files.. You
just need the people who maintain the files.
how about this,
git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl | wc
58 163 2169
That's the patch we're actually discussing too. It's about one CC per
file modified.
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Russell King @ 2010-10-18 21:58 UTC (permalink / raw)
To: Daniel Walker
Cc: Nicolas Pitre, Stephen Rothwell, linux-next, linux-kernel,
Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <1287437362.5588.57.camel@c-dwalke-linux.qualcomm.com>
On Mon, Oct 18, 2010 at 02:29:22PM -0700, Daniel Walker wrote:
> That's why we have get_maintainer.pl, it adds in all the CC's
> automatically ..
$ git diff-tree -u 861bd81ee62a0d6759144c22909a8a3938951656 | scripts/get_maintainer.pl |wc
209 624 8021
209 recipients / 8K of To:/CC: is reasonable?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-18 21:35 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Arnd Bergmann, Russell King, Stephen Rothwell, linux-next,
linux-kernel, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <alpine.LFD.2.00.1010181714090.2764@xanadu.home>
On Mon, 2010-10-18 at 17:17 -0400, Nicolas Pitre wrote:
> On Mon, 18 Oct 2010, Daniel Walker wrote:
>
> > I guess your assuming I send my pull request after Russell's, which
> > isn't necessarily true, and I'd rather not have that dependency if I
> > don't have to.
>
> Look, we're not establishing a straight rule here -- just figuring out a
> way to move forward. What we're asking you to do is either ask RMK to
> pull your tree now, or wait until RMK's tree has hit mainline so you can
> pull Linus' tree and fix the issue yourself before asking Linus to pull,
> or whatever. Is some collaboration on your part for this particular
> issue too much to ask for?
I'm always very cooperative, if you read back in the thread I basically
suggested I would be sending a pull request to Russell. That was prior
to Arnd'd comments.
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-18 21:29 UTC (permalink / raw)
To: Russell King
Cc: Nicolas Pitre, Stephen Rothwell, linux-next, linux-kernel,
Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <20101018205847.GB23642@flint.arm.linux.org.uk>
On Mon, 2010-10-18 at 21:58 +0100, Russell King wrote:
> On Mon, Oct 18, 2010 at 01:12:54PM -0700, Daniel Walker wrote:
> > On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
> >
> > > > Ok, well in that case why not accept this immediately after the merge
> > > > window? A point when everything is quiet, and most of the tree's are
> > > > empty?
> > >
> > > RMK has his own merge window which closes about at the same time as
> > > Linus' one opens. We thought this was happening last week and therefore
> > > this change was supposed to be the last one.
> >
> > It seems like that could potentially make these kinds of problem worse,
> > since your merging things immediately before sending them to Linus. Like
> > right now we only have a fairly short amount of time to correct this
> > conflict.
>
> What I would like to do in an ideal world is stop merging stuff into my
> tree one week before the merge window opens precisely so that people can
> regression test it. If I were to conform to that, I'd be saying "tough,
> it's your problem" right now. Why?
>
> This change has been discussed at length on the linux-arm-kernel mailing
> list, where patches have been posted and reviewed for it several times
> since July:
>
> http://marc.info/?l=linux-arm-kernel&w=2&r=1&s=late+mdesc&q=b
>
> In September it became ready for merging, and this is what I said:
>
> http://marc.info/?l=linux-arm-kernel&m=128332699032679&w=2
>
> So, there should be absolutely no surprise over it, except from people
> who ignore what's going on in the generic ARM world. No, you can't
> expect people to copy every single board maintainer - we have something
> like 300 odd board files with various maintainers. It's one of the
> reasons that we have mailing lists.
That's why we have get_maintainer.pl, it adds in all the CC's
automatically .. I can notice the thread on the list, but I have no idea
it's modifying my tree unless I examine every patch's diffstat .. To me
it's way more reasonable to ask the patch author to get the CC's right.
That way we all get active notification when something is modifying our
tree's ..
> What I should be saying at this point is "tough, you've got a problem"
> but I won't. I've rewound my tree to drop these changes, because it
> seems several people need more time. You have it - until Tuesday - when
> Nicolas will re-do his patch set on top of whatever my tree is at that
> point.
>
> If you haven't sent me a pull request by Tuesday[*] evening my time, it
> becomes _your_ problem to fix the resulting breakage. A warning: make
> sure your tree is not based on my devel branch - it's regressed to
> 'unstable' state because of this.
>
Ok ..
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Nicolas Pitre @ 2010-10-18 21:17 UTC (permalink / raw)
To: Daniel Walker
Cc: Arnd Bergmann, Russell King, Stephen Rothwell, linux-next,
linux-kernel, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <1287435928.5588.37.camel@c-dwalke-linux.qualcomm.com>
On Mon, 18 Oct 2010, Daniel Walker wrote:
> I guess your assuming I send my pull request after Russell's, which
> isn't necessarily true, and I'd rather not have that dependency if I
> don't have to.
Look, we're not establishing a straight rule here -- just figuring out a
way to move forward. What we're asking you to do is either ask RMK to
pull your tree now, or wait until RMK's tree has hit mainline so you can
pull Linus' tree and fix the issue yourself before asking Linus to pull,
or whatever. Is some collaboration on your part for this particular
issue too much to ask for?
Nicolas
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Nicolas Pitre @ 2010-10-18 21:11 UTC (permalink / raw)
To: Daniel Walker
Cc: Arnd Bergmann, Russell King, Stephen Rothwell, linux-next,
linux-kernel, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <1287434251.5588.23.camel@c-dwalke-linux.qualcomm.com>
On Mon, 18 Oct 2010, Daniel Walker wrote:
> I think the term "merge window" is a little mis-leading here.. Your
> describing development. To me the term merge window is indicating a
> short period when you get changes in, not the whole -rc cycle.
There are overlaps. The two-week merge window is for subsystem
maintainers to push their stuff to Linus. Obviously those subsystem
maintainers must have merge windows of their own prior pushing their
tree to Linus. This is a pipeline.
And folks let's not get too excited about this. The idea of having this
change at the end of RMK's merge window is to catch most (if not all)
ARM targets being affected. Last time I checked this affected something
like 367 machines. This is not a catastrophic issue if support for one
or two machines get merged outside of RMK's tree and a build error
happens for them once in Linus' tree. The fix should be obvious and the
-rc period is long enough to fix those things. Or the merge actually
flags a conflict that should be trivial to fix as Stephen did in
linux-next.
Merge conflicts do happen. If those conflicts remain small and trivial
this is _fine_.
Nicolas
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-18 21:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Nicolas Pitre, Russell King, Stephen Rothwell, linux-next,
linux-kernel, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <201010182248.36078.arnd@arndb.de>
On Mon, 2010-10-18 at 22:48 +0200, Arnd Bergmann wrote:
> On Monday 18 October 2010 22:37:31 Daniel Walker wrote:
> > > When you know that Russell does not rebase his tree, you can pull his
> > > tree into yours whenever a change hits his tree that impacts you in
> > > a major way. You shouldn't do this too frequently, but it's a good way
> > > to resolve conflicts like this one.
> >
> > If I did that all of Russell's changesets would get mixed with mine when
> > I send the pull request .. That would just create confusion .. It's OK
> > if Russell sends my commits to Linus, but I'm not going to send
> > Russell's commits.
>
> Actually both are ok, as long as you as the sub-maintainer send your
> pull request after Russell's tree has been merged and you don't
> ask anyone else to pull your tree who has not pulled Russell's tree
> explicitly or implicitly through Linus.
>
> git-request-pull is smart enough to list only the changesets that
> are not in the upstream tree, as will git "log your-branch...upstream"
> or "git diff your-branch upstream".
I guess your assuming I send my pull request after Russell's, which
isn't necessarily true, and I'd rather not have that dependency if I
don't have to.
Even with a one time event what your suggesting seems like it would be
some what freaky. I wouldn't want to wait around for Russell to get his
tree merged before I can get a reasonable log of my own activities
(without jumping through hoops).
Of course I could do what your suggesting, I just don't think it's the
easiest way to fix this.
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Russell King @ 2010-10-18 20:58 UTC (permalink / raw)
To: Daniel Walker
Cc: Nicolas Pitre, Stephen Rothwell, linux-next, linux-kernel,
Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <1287432774.5588.5.camel@c-dwalke-linux.qualcomm.com>
On Mon, Oct 18, 2010 at 01:12:54PM -0700, Daniel Walker wrote:
> On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
>
> > > Ok, well in that case why not accept this immediately after the merge
> > > window? A point when everything is quiet, and most of the tree's are
> > > empty?
> >
> > RMK has his own merge window which closes about at the same time as
> > Linus' one opens. We thought this was happening last week and therefore
> > this change was supposed to be the last one.
>
> It seems like that could potentially make these kinds of problem worse,
> since your merging things immediately before sending them to Linus. Like
> right now we only have a fairly short amount of time to correct this
> conflict.
What I would like to do in an ideal world is stop merging stuff into my
tree one week before the merge window opens precisely so that people can
regression test it. If I were to conform to that, I'd be saying "tough,
it's your problem" right now. Why?
This change has been discussed at length on the linux-arm-kernel mailing
list, where patches have been posted and reviewed for it several times
since July:
http://marc.info/?l=linux-arm-kernel&w=2&r=1&s=late+mdesc&q=b
In September it became ready for merging, and this is what I said:
http://marc.info/?l=linux-arm-kernel&m=128332699032679&w=2
So, there should be absolutely no surprise over it, except from people
who ignore what's going on in the generic ARM world. No, you can't
expect people to copy every single board maintainer - we have something
like 300 odd board files with various maintainers. It's one of the
reasons that we have mailing lists.
What I should be saying at this point is "tough, you've got a problem"
but I won't. I've rewound my tree to drop these changes, because it
seems several people need more time. You have it - until Tuesday - when
Nicolas will re-do his patch set on top of whatever my tree is at that
point.
If you haven't sent me a pull request by Tuesday[*] evening my time, it
becomes _your_ problem to fix the resulting breakage. A warning: make
sure your tree is not based on my devel branch - it's regressed to
'unstable' state because of this.
You have the opportunity to sort this out avoiding conflicts and bisect
problems. I suggest you take advantage of that. But don't expect me
to keep on making these kinds of concessions.
* - I really don't like making deadlines for Tuesdays and Wednesdays
because I tend to only be around in the evening - but there is no option.
So don't expect something which arrives here at midnight Tuesday to get
merged.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Nicolas Pitre @ 2010-10-18 20:57 UTC (permalink / raw)
To: Daniel Walker
Cc: Russell King, Stephen Rothwell, linux-next, linux-kernel,
Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <1287433179.5588.9.camel@c-dwalke-linux.qualcomm.com>
On Mon, 18 Oct 2010, Daniel Walker wrote:
> On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
>
> > RMK has his own merge window which closes about at the same time as
> > Linus' one opens. We thought this was happening last week and therefore
> > this change was supposed to be the last one.
>
> I guess what I'm missing here is when does this window open? Is it a two
> week deal, or does it last the whole -rc cycle?
Linus' merge window is indeed the two-week thing. No one can predict
with certainty when it'll happen, as demonstrated by our merging of the
debug macro in RMK's tree last week based on the presumption that we
would be in the two-week merge now.
Nicolas
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Arnd Bergmann @ 2010-10-18 20:48 UTC (permalink / raw)
To: Daniel Walker
Cc: Nicolas Pitre, Russell King, Stephen Rothwell, linux-next,
linux-kernel, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <1287434251.5588.23.camel@c-dwalke-linux.qualcomm.com>
On Monday 18 October 2010 22:37:31 Daniel Walker wrote:
> > When you know that Russell does not rebase his tree, you can pull his
> > tree into yours whenever a change hits his tree that impacts you in
> > a major way. You shouldn't do this too frequently, but it's a good way
> > to resolve conflicts like this one.
>
> If I did that all of Russell's changesets would get mixed with mine when
> I send the pull request .. That would just create confusion .. It's OK
> if Russell sends my commits to Linus, but I'm not going to send
> Russell's commits.
Actually both are ok, as long as you as the sub-maintainer send your
pull request after Russell's tree has been merged and you don't
ask anyone else to pull your tree who has not pulled Russell's tree
explicitly or implicitly through Linus.
git-request-pull is smart enough to list only the changesets that
are not in the upstream tree, as will git "log your-branch...upstream"
or "git diff your-branch upstream".
The other option you have is to ask Russell to pull your tree
at an early enough time, which also works if you did the occasional
pull from him before that.
Arnd
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-18 20:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Nicolas Pitre, Russell King, Stephen Rothwell, linux-next,
linux-kernel, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <201010182219.25890.arnd@arndb.de>
On Mon, 2010-10-18 at 22:19 +0200, Arnd Bergmann wrote:
> On Monday 18 October 2010 22:12:54 Daniel Walker wrote:
> > On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
> >
> > > > Ok, well in that case why not accept this immediately after the merge
> > > > window? A point when everything is quiet, and most of the tree's are
> > > > empty?
> > >
> > > RMK has his own merge window which closes about at the same time as
> > > Linus' one opens. We thought this was happening last week and therefore
> > > this change was supposed to be the last one.
> >
> > It seems like that could potentially make these kinds of problem worse,
> > since your merging things immediately before sending them to Linus. Like
> > right now we only have a fairly short amount of time to correct this
> > conflict.
>
> What Nicolas was talking about is the *end* of the merge window, not the
> start. This is how all sensible maintainer trees work: you get to
> merge stuff into the maintainer tree for a number of weeks (some start
> at -rc1, other start a bit later). When Linus tells people to get ready
> for the release, the subsystem goes into regression fix mode and when
> Linus opens his merge window, everything should be reasonably stable.
I think the term "merge window" is a little mis-leading here.. Your
describing development. To me the term merge window is indicating a
short period when you get changes in, not the whole -rc cycle.
> > > > Well how about I merge this change into my tree ?
> > >
> > > If you ask RMK to merge your tree in his that would be much simpler to
> > > add this change in a single pass afterwards.
> >
> > I can do that , but would I still be able to merge stuff into my tree?
> > Seems like I could, Russell would just clean up the conflict and my tree
> > would just move forward like it has been already , and I would send the
> > whole thing to Linus.
>
> When you know that Russell does not rebase his tree, you can pull his
> tree into yours whenever a change hits his tree that impacts you in
> a major way. You shouldn't do this too frequently, but it's a good way
> to resolve conflicts like this one.
If I did that all of Russell's changesets would get mixed with mine when
I send the pull request .. That would just create confusion .. It's OK
if Russell sends my commits to Linus, but I'm not going to send
Russell's commits.
Daniel
^ permalink raw reply
* RE: linux-next: build failure after merge of the sound-asoc tree
From: Peter Hsiang @ 2010-10-18 20:25 UTC (permalink / raw)
To: Stephen Rothwell, Mark Brown, Liam Girdwood
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20101018142934.65f5d0fa.sfr@canb.auug.org.au>
On Sun, Oct 17, 2010, Stephen Rothwell wrote:
> Hi all,
>
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> sound/soc/codecs/max98088.c:28:28: error: sound/max98088.h: No such file or
> directory
>
Mark,
This message seems to be saying that this header file is missing.
However, this header file was included in the patch that was submitted,
and it did compile fine here before the submit.
I don't understand why it's not there after it was applied?
Thanks,
Peter
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (mmc tree related)
From: Chris Ball @ 2010-10-18 20:24 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Wolfram Sang, linux-mmc
In-Reply-To: <20101018183540.2a7dfc8f.sfr@canb.auug.org.au>
Hi Stephen,
On Mon, Oct 18, 2010 at 06:35:40PM +1100, Stephen Rothwell wrote:
> After merging the scsi-post-merge tree, today's linux-next build ()
> failed like this:
[...]
> Caused by commit a2fe088a5aaa51b54c018cf309cdc728d5f4e540 ("mmc:
> sdhci-of-esdhc: factor out common stuff").
>
> This was clearly never build tested ...
>
> I have reverted that commit for today.
Sorry about this -- you're right, my test compile missed this patch.
I've pushed a tested fix now.
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-18 20:19 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King, Stephen Rothwell, linux-next, linux-kernel,
Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <alpine.LFD.2.00.1010181525000.2764@xanadu.home>
On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
> RMK has his own merge window which closes about at the same time as
> Linus' one opens. We thought this was happening last week and therefore
> this change was supposed to be the last one.
I guess what I'm missing here is when does this window open? Is it a two
week deal, or does it last the whole -rc cycle?
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Arnd Bergmann @ 2010-10-18 20:19 UTC (permalink / raw)
To: Daniel Walker
Cc: Nicolas Pitre, Russell King, Stephen Rothwell, linux-next,
linux-kernel, Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <1287432774.5588.5.camel@c-dwalke-linux.qualcomm.com>
On Monday 18 October 2010 22:12:54 Daniel Walker wrote:
> On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
>
> > > Ok, well in that case why not accept this immediately after the merge
> > > window? A point when everything is quiet, and most of the tree's are
> > > empty?
> >
> > RMK has his own merge window which closes about at the same time as
> > Linus' one opens. We thought this was happening last week and therefore
> > this change was supposed to be the last one.
>
> It seems like that could potentially make these kinds of problem worse,
> since your merging things immediately before sending them to Linus. Like
> right now we only have a fairly short amount of time to correct this
> conflict.
What Nicolas was talking about is the *end* of the merge window, not the
start. This is how all sensible maintainer trees work: you get to
merge stuff into the maintainer tree for a number of weeks (some start
at -rc1, other start a bit later). When Linus tells people to get ready
for the release, the subsystem goes into regression fix mode and when
Linus opens his merge window, everything should be reasonably stable.
> > > Well how about I merge this change into my tree ?
> >
> > If you ask RMK to merge your tree in his that would be much simpler to
> > add this change in a single pass afterwards.
>
> I can do that , but would I still be able to merge stuff into my tree?
> Seems like I could, Russell would just clean up the conflict and my tree
> would just move forward like it has been already , and I would send the
> whole thing to Linus.
When you know that Russell does not rebase his tree, you can pull his
tree into yours whenever a change hits his tree that impacts you in
a major way. You shouldn't do this too frequently, but it's a good way
to resolve conflicts like this one.
Arnd
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-18 20:12 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King, Stephen Rothwell, linux-next, linux-kernel,
Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <alpine.LFD.2.00.1010181525000.2764@xanadu.home>
On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
> > Ok, well in that case why not accept this immediately after the merge
> > window? A point when everything is quiet, and most of the tree's are
> > empty?
>
> RMK has his own merge window which closes about at the same time as
> Linus' one opens. We thought this was happening last week and therefore
> this change was supposed to be the last one.
It seems like that could potentially make these kinds of problem worse,
since your merging things immediately before sending them to Linus. Like
right now we only have a fairly short amount of time to correct this
conflict.
> > Well how about I merge this change into my tree ?
>
> If you ask RMK to merge your tree in his that would be much simpler to
> add this change in a single pass afterwards.
I can do that , but would I still be able to merge stuff into my tree?
Seems like I could, Russell would just clean up the conflict and my tree
would just move forward like it has been already , and I would send the
whole thing to Linus.
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Nicolas Pitre @ 2010-10-18 19:29 UTC (permalink / raw)
To: Daniel Walker
Cc: Russell King, Stephen Rothwell, linux-next, linux-kernel,
Jeremy Kerr, Jeff Ohlstein
In-Reply-To: <1287427572.4105.22.camel@c-dwalke-linux.qualcomm.com>
On Mon, 18 Oct 2010, Daniel Walker wrote:
> On Mon, 2010-10-18 at 19:20 +0100, Russell King wrote:
> > On Mon, Oct 18, 2010 at 10:26:32AM -0700, Daniel Walker wrote:
> > > On Mon, 2010-10-18 at 09:15 +0100, Russell King wrote:
> > > > On Mon, Oct 18, 2010 at 11:02:07AM +1100, Stephen Rothwell wrote:
> > > > > [ Just cc'ing Russell, sorry about that]
> > > > >
> > > > > On Mon, 18 Oct 2010 10:35:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > >
> > > > > > Hi Daniel,
> > > > > >
> > > > > > Today's linux-next merge of the msm tree got a conflict in
> > > > > > arch/arm/mach-msm/include/mach/debug-macro.S between commit
> > > > > > 08a610d9ef5394525b0328da0162d7b58c982cc4 ("arm: return both physical and
> > > > > > virtual addresses from addruart") from the arm tree and commit
> > > > > > 46fe5f29e3062f681cc3cf07a604d82396faea89 ("msm: allow uart to be
> > > > > > conditionally disabled") from the msm tree.
> > > > > >
> > > > > > Just context changes. I fixed it up (see below) and can carry the fix as
> > > > > > necessary.
> > > >
> > > > Thanks, but I don't think there's much which can be done about these.
> > > > Changes such as 08a610d affect all ARM sub-architectures, and as they're
> > > > spread across multiple git trees...
> > > >
> > > > I think there's going to be some problems during this forthcoming merge
> > > > window.
> > >
> > > Would be nice to get CC'd ...
> > >
> > > Ideally this patch should have been broken up and sent individually to
> > > each maintainer .. Then I could manage this within my own tree..
> >
> > Err no. It is one complete change which can't be broken up sensibly.
> > Breaking it up will mean either you lose functionality or you break
> > your build.
>
>
> Ok, well in that case why not accept this immediately after the merge
> window? A point when everything is quiet, and most of the tree's are
> empty?
RMK has his own merge window which closes about at the same time as
Linus' one opens. We thought this was happening last week and therefore
this change was supposed to be the last one.
> Well how about I merge this change into my tree ?
If you ask RMK to merge your tree in his that would be much simpler to
add this change in a single pass afterwards.
Nicolas
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-18 18:46 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, linux-next, linux-kernel, Jeremy Kerr,
Jeff Ohlstein
In-Reply-To: <20101018182044.GA558@flint.arm.linux.org.uk>
On Mon, 2010-10-18 at 19:20 +0100, Russell King wrote:
> On Mon, Oct 18, 2010 at 10:26:32AM -0700, Daniel Walker wrote:
> > On Mon, 2010-10-18 at 09:15 +0100, Russell King wrote:
> > > On Mon, Oct 18, 2010 at 11:02:07AM +1100, Stephen Rothwell wrote:
> > > > [ Just cc'ing Russell, sorry about that]
> > > >
> > > > On Mon, 18 Oct 2010 10:35:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > Today's linux-next merge of the msm tree got a conflict in
> > > > > arch/arm/mach-msm/include/mach/debug-macro.S between commit
> > > > > 08a610d9ef5394525b0328da0162d7b58c982cc4 ("arm: return both physical and
> > > > > virtual addresses from addruart") from the arm tree and commit
> > > > > 46fe5f29e3062f681cc3cf07a604d82396faea89 ("msm: allow uart to be
> > > > > conditionally disabled") from the msm tree.
> > > > >
> > > > > Just context changes. I fixed it up (see below) and can carry the fix as
> > > > > necessary.
> > >
> > > Thanks, but I don't think there's much which can be done about these.
> > > Changes such as 08a610d affect all ARM sub-architectures, and as they're
> > > spread across multiple git trees...
> > >
> > > I think there's going to be some problems during this forthcoming merge
> > > window.
> >
> > Would be nice to get CC'd ...
> >
> > Ideally this patch should have been broken up and sent individually to
> > each maintainer .. Then I could manage this within my own tree..
>
> Err no. It is one complete change which can't be broken up sensibly.
> Breaking it up will mean either you lose functionality or you break
> your build.
Ok, well in that case why not accept this immediately after the merge
window? A point when everything is quiet, and most of the tree's are
empty?
Well how about I merge this change into my tree ?
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Russell King @ 2010-10-18 18:20 UTC (permalink / raw)
To: Daniel Walker
Cc: Stephen Rothwell, linux-next, linux-kernel, Jeremy Kerr,
Jeff Ohlstein
In-Reply-To: <1287422792.4105.14.camel@c-dwalke-linux.qualcomm.com>
On Mon, Oct 18, 2010 at 10:26:32AM -0700, Daniel Walker wrote:
> On Mon, 2010-10-18 at 09:15 +0100, Russell King wrote:
> > On Mon, Oct 18, 2010 at 11:02:07AM +1100, Stephen Rothwell wrote:
> > > [ Just cc'ing Russell, sorry about that]
> > >
> > > On Mon, 18 Oct 2010 10:35:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > Hi Daniel,
> > > >
> > > > Today's linux-next merge of the msm tree got a conflict in
> > > > arch/arm/mach-msm/include/mach/debug-macro.S between commit
> > > > 08a610d9ef5394525b0328da0162d7b58c982cc4 ("arm: return both physical and
> > > > virtual addresses from addruart") from the arm tree and commit
> > > > 46fe5f29e3062f681cc3cf07a604d82396faea89 ("msm: allow uart to be
> > > > conditionally disabled") from the msm tree.
> > > >
> > > > Just context changes. I fixed it up (see below) and can carry the fix as
> > > > necessary.
> >
> > Thanks, but I don't think there's much which can be done about these.
> > Changes such as 08a610d affect all ARM sub-architectures, and as they're
> > spread across multiple git trees...
> >
> > I think there's going to be some problems during this forthcoming merge
> > window.
>
> Would be nice to get CC'd ...
>
> Ideally this patch should have been broken up and sent individually to
> each maintainer .. Then I could manage this within my own tree..
Err no. It is one complete change which can't be broken up sensibly.
Breaking it up will mean either you lose functionality or you break
your build.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: linux-next: manual merge of the msm tree with the arm tree
From: Daniel Walker @ 2010-10-18 17:26 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, linux-next, linux-kernel, Jeremy Kerr,
Jeff Ohlstein
In-Reply-To: <20101018081520.GA10551@flint.arm.linux.org.uk>
On Mon, 2010-10-18 at 09:15 +0100, Russell King wrote:
> On Mon, Oct 18, 2010 at 11:02:07AM +1100, Stephen Rothwell wrote:
> > [ Just cc'ing Russell, sorry about that]
> >
> > On Mon, 18 Oct 2010 10:35:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Hi Daniel,
> > >
> > > Today's linux-next merge of the msm tree got a conflict in
> > > arch/arm/mach-msm/include/mach/debug-macro.S between commit
> > > 08a610d9ef5394525b0328da0162d7b58c982cc4 ("arm: return both physical and
> > > virtual addresses from addruart") from the arm tree and commit
> > > 46fe5f29e3062f681cc3cf07a604d82396faea89 ("msm: allow uart to be
> > > conditionally disabled") from the msm tree.
> > >
> > > Just context changes. I fixed it up (see below) and can carry the fix as
> > > necessary.
>
> Thanks, but I don't think there's much which can be done about these.
> Changes such as 08a610d affect all ARM sub-architectures, and as they're
> spread across multiple git trees...
>
> I think there's going to be some problems during this forthcoming merge
> window.
Would be nice to get CC'd ...
Ideally this patch should have been broken up and sent individually to
each maintainer .. Then I could manage this within my own tree..
Daniel
^ permalink raw reply
* Re: linux-next: manual merge of the xen tree with the swiotlb-xen tree
From: Stephen Rothwell @ 2010-10-18 14:49 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Jeremy Fitzhardinge, Xen Devel, linux-next, linux-kernel,
Andrew Morton, Linus
In-Reply-To: <20101018135512.GA19999@dumpdata.com>
[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]
Hi Konrad,
On Mon, 18 Oct 2010 09:55:12 -0400 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>
> Since I seem to have a knack for making mistakes, let me get some clarification
> so that I won't do it again.
>
> When is it Ok for me to put in the #linux-next, new stable features (so
> reviewed, acked, etc)? a) Is it post rc7? b) Or is it when Linus releases
> the kernel and Linus's merge window opens?
Stuff destined for 2.6.n should be enter linux-next (after being posted,
reviewed and tested) between 2.6.(n-1)-rc1 and about 2 weeks before 2.6.
(n-1) (usually -rc6 or 7). That way, hopefully we will have most
integration problems sorted out before Linus releases 2.6.(n-1) and the
code can go into Linus' tree during the merge window. We can then sort
out any bugs etc in Linus's tree during the -rc releases for 2.6.n (at
the same time putting features for 2.6.(n+1) into linux-next.
So the answer is c) pre -rc7 :-)
i.e. all the new features for 2.6.37 should have been in linux-next at
least a week ago ...
In an idea world, the week before the merge window should be spent
settling stuff down ready to go into Linus' tree. In the real world,
everyone seems to madly shove their new features into linux-next, rebase
their trees against some recent version of Linus' tree or do merges with
his tree (sometimes all three). A lot of this latter is completely
unnecessary and just means that all the previous testing is thrown away
with the introduction of more code from Linus' tree.
Have a look at the graphs at http://neuling.org/linux-next-size.html .
In the last week, we have had ~930 new commits enter linux-next (that is
over 12% of the total in linux-next). Since -rc7 came out, that number
is 1580 commits (over 20%). So instead of flattening off (and
stabilising) as we approach the merge window, the rate of change tends to
accelerate ...
/me gets off his soap box :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the xen tree with the swiotlb-xen tree
From: Konrad Rzeszutek Wilk @ 2010-10-18 13:55 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Stephen Rothwell, Xen Devel, linux-next, linux-kernel,
Andrew Morton, Linus
In-Reply-To: <4CBC014D.7070302@goop.org>
On Mon, Oct 18, 2010 at 01:11:57AM -0700, Jeremy Fitzhardinge wrote:
> On 10/17/2010 09:52 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the xen tree got conplex conflicts in
> > drivers/xen/events.c between several commits from the swiotlb-xen tree
> > and several commits from the xen tree.
> >
> > I am unqualified to fix this mess, sorry. I am dropping the xen tree
> > for today (and only not dropping the swiotlb-xen tree because that would
> > be too much work).
Ugh. Let me revert the branch to pull this from to what it was a week ago.
That way Jeremy's tree should not have any trouble.
>
> Argh, sorry, I should have coordinated with Konrad. I'd merged my tree
> into linux-next to make sure it was OK, but I guess I overlooked something.
>
> > I wonder, of course, why I have seen nothing in either of these trees
> > until today (less than a week before the merge window opens).
That is my fault. I thought the merge window was this _week_ so I happily
pushed the trigger button.
Since I seem to have a knack for making mistakes, let me get some clarification
so that I won't do it again.
When is it Ok for me to put in the #linux-next, new stable features (so
reviewed, acked, etc)? a) Is it post rc7? b) Or is it when Linus releases
the kernel and Linus's merge window opens?
I was thinking it is a), b/c if it would be b), then there is just two weeks
to fix any fallout that might happen due to merging of vast new features.
>
> I had found Xen regressions that had made it into linux-next and wanted
> to sort those out before adding anything else to the mix.
>
> > Please sort this mess out. I will drop the swiotlb-xen tree as well
> > tomorrow if nothing has changed.
>
> Will do.
Sorry about this. Will definitly work this out.
>
> Thanks,
> J
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox