[GIT PULL] pxa: patches for next merge window
torvalds at linux-foundation.org
Mon Mar 1 11:40:26 EST 2010
On Mon, 1 Mar 2010, Russell King - ARM Linux wrote:
> On Mon, Mar 01, 2010 at 10:39:27AM +0100, Uwe Kleine-König wrote:
> > In my eyes there are three different possibilities for the future:
> > a) every tree requested for pulling has to keep constant.
> > b) rmk treats the submaintainer trees as his topic branches that are
> > regularly merged into devel.
> > c) Linus pulls directly from submaintainers.
> > I think c) isn't nice (and AFAIK Linus would request a)).
> > I'd prefer a). And if a submaintainer "doesn't behave" next time either
> > both trees are pulled making the arm tree as ugly as are the others
> > sometimes or the second pull request is declined if Russell notes it
> > early enough (maybe supported by some script work).
> I've added Linus to this, so he's aware of what's going on, since if
> I do merge Eric's latest tree, Linus will see duplicate commits from
> me and I don't wish to have one of Linus' responses to that. ;)
> The general rule is that once you've asked someone to pull your tree,
> that's it, the commits are cast in stone. It doesn't matter who you
> ask to pull your tree.
Yes. I think (a) is the right thing to do, ie if rmk is pulling from
others, then those others must always follow the same rules that _I_
require people I pull from to follow.
Quite frankly, (b) is going to be a total mess. It's been done. The
resulting 'devel' branch will end up looking like 'next', and while
there's no question that 'next' isn't very useful, it's also almost
totally impossible to look through the history of it when things go wrong
(git has 'rerere' to remember previous merge resolutions so that they
don't have to be re-done over and over again, but that's about the only
kind of "history of history" that git helps with).
And while (c) is something I do, it's something I want to do
_occasionally_ rather than all the time. IOW, I'll happily take direct
pulls from submaintainers, but I'd rather have a good reason for it (ie
maintainer is temporarily busy with something else, or it's an urgent fix
late in the -rc series that somebody just wants to happen asap etc).
So I'd much prefer (a). And that does mean that submaintainers have to be
IOW, if a submaintainer ask somebody else to pull from them, that tree is
now public, and cannot then be rebased or do other history-destroying
This obviously does require that submaintainers be more careful, but
that's a _good_ thing. They need to think twice before asking their
higher-up maintainer to pull their stuff, because once it's pulled, it's
set in stone.
rmk: I think it's ok if you end up having to rebase something this time in
order to fix up a mistake that has already happened - no rule should be
_so_ set in stone that it can't be violated when bad things happen.
But you could be hard-nosed and push the pain downward (that's what I tend
to try to do), ie do something like force your submaintainers to go back
to the old state that you already pulled from, and then rebase their
subsequent changes on top of that.
The reason _I_ tend to push the pain back down is (a) I'm lazy, and I damn
well like it that way and (b) I also happen to think that it's
fundamentally much better to "spread out" the pain as widely as possible
than have it concentrate at some maintainer level.
So not only for me personally, but in general, I think it's better if we
strive to push the burden of maintenance as far out as possible. That way
the development model scales, rather than become too tied up with
particular maintainers having to be really really on top of everything.
More information about the linux-arm-kernel