On Tue, Feb 12, 2008 at 09:00:16PM -0600, James Bottomley wrote:
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.
--
