Re: Announce: Linux-next (Or Andrew's dream :-))

[Paul Mundt]

On Tue, Feb 12, 2008 at 09:00:16PM -0600, James Bottomley wrote:
> On Tue, 2008-02-12 at 18:35 -0800, Linus Torvalds wrote:
> > 
> > On Tue, 12 Feb 2008, James Bottomley wrote:
> > > 
> > > Yes, this is exactly the feature I'm looking for.  It would allow the
> > > downstream users of a rebased tree to rebase themselves correctly.
> > > 
> > > All the information about the rebase is in the reflog ... it can't be
> > > too difficult to pass it through on a pull and allow the downstream tree
> > > to do the right thing.
> > 
> > Guys, you simply have no idea what you're talking about.
> > 
> > Those downstream trees can have done things themselves. They *depended* on 
> > the state you gave them.
> > 
> > You can't just say "oops, I lied, this is the state you should have used, 
> > now it's _your_ mess to sort out".
> > 
> > OF COURSE it's what you'd like to use - it absolves you of any and all 
> > actual responsibility. But dammit, that's not what anybody else wants than 
> > the irresponsible person who cannot be bothered to stand up for his work!
> > 
> > If you're not confident enough about your work, don't push it out! It's 
> > that simple. Pushing out to a public branch is a small "release".
> > 
> > Have the f*cking back-bone to be able to stand behind what you did!
> 
> Erm, I would like this feature as a downstream user.
> 
> I'm not asking for this to be the default or even easily available.
> However, when you know you've based a downstream tree on what you know
> to be a volatile base, it would be very useful information to have.
> 
> Right at the moment, I maintain a <branch> and a <branch>-base and
> simply cherry pick the commits between the two to do the right thing
> when I know my volatile base has changed.  It would be very helpful to
> have a version of rebase that new my base had been rebased.
> 
> Basing on a tree I know to be volatile is sometimes a development
> decision I make as a downstream user ... I'm just wishing the tools
> could help me handle the problems better.
> 
There's also a difference between a downstream user and a downstream
developer. While rebasing does cause trouble for folks doing downstream
development off of the tree in question, there's no reason why this
should be the case for users that are simply trying to follow the tree.

I push changes out to my tree so people have a chance to poke through it
and to see what's going on, though I do not generally encourage people to
fork off of it given that I end up rebasing periodically. At the moment
the options seem to be down to the following:

	1 - Push changes out without rebasing
	2 - Push changes out periodically rebased
	3 - Hide the tree away in my home directory on hera
	4 - Force people to get at the current tree through -mm

4) generally isn't very realistic, given that -mm releases have far too
many other changes and the releases are quite spread out. 3) is doable,
but I publish the tree as a convenience to the folks wanting to see
what's going on in the tree, and I would rather continue doing so.

This leaves 2) my current workflow, and 1) which ends up creating a
lot of extra metadata. The common cases thelre are patches + reversions
and merge points. Holding on to a patch for some period of time before
pushing it out to ensure that there won't be a reversion later rarely
tends to work in practice. Most of the time I end up having to revert
something it's because someone else found a problem with a given change
_after_ the it was pushed out, and which was not caught with my local
tree or testing.

On the other hand, perhaps it's also useful to see the reversions in the
history, particularly to see what the rationale for the change not
working out was (which could be helpful for people working on the same
stuff later on).

This then leaves merge points. During merge window time people are
pulling on a pretty frequent basis, which also breaks down to a few
fairly common cases:

	1 - Bringing in new stuff to be supported (ie, system calls).
	2 - Infrastructure support bits that have gone in through a
	    subsystem tree, when you have local patches blocked until the
	    subsystem tree has merge.
	3 - Catching and resolving conflicts before bisect gets broken.
	4 - Trying to make sure that it all merges cleanly.

I've generally worked around 2) by doing multiple merges during the merge
window, but it's also appealing to just rebase and throw in the rest of
the outstanding bits before sending out the initial merge request.

1) and 3) often tend to have dependencies on each other, and tend to be
the area where the most troubles arise. 3) and 4) are really the places
where rebasing appeals the most, and is also where we see the highest
concentration of merge points.

If there's a nice way to resolve this without a rebase that would be
nice. For users in general, I suspect most people are just interested in
a pull that can traverse a rebase without having them wipe the tree. Most
users that are tracking a tree of interest seem to understand that a
development tree is highly volatile during merge window time, and that
they track the tree knowing that they will occasionally have to toss it
and start over when it's rebased. Having a way to simplify this that
doesn't create an additional maintenance burden would be ideal. I suspect
that if people are never rebasing in publicly visible trees, we will
simply see a shift to unpublished trees instead, which doesn't seem to be
what anyone wants either.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/