[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable
James.Bottomley at HansenPartnership.com
Tue Jun 19 09:34:00 UTC 2012
On Tue, 2012-06-19 at 01:02 -0700, Olof Johansson wrote:
> On Mon, Jun 18, 2012 at 12:36 AM, James Bottomley
> <James.Bottomley at hansenpartnership.com> wrote:
> > On Sun, 2012-06-17 at 15:32 -0700, Olof Johansson wrote:
> >> The biggest one is that it _has to_ be a stable branch. No rebases are
> >> allowed by the other subsystem maintainer of these patches since it
> >> will cause merge conflicts. Ideal is if the dependent code is on a
> >> small single-topic branch in their tree and they merge that into their
> >> for-next (and merge it into the branch they ask Linus to pull). Due to
> >> miscommunication early on we had a couple of cases where the other
> >> subsystem maintainer was unaware of our dependency and requirement,
> >> and rebased before sending a pull request. It got caught in -next but
> >> it was still messy for everyone to resolve.
> > So, actually, we solved this one in SCSI. We run something we call a
> > postmerge tree which is made up of whatever the dependent initial trees
> > are with the relevant SCSI patches on top. However, the tree has two
> > branches: xxx-base and xxx. linux-next treats the tree specially and
> > pulls in (via a rebase) from xxx-base to xxx meaning that the dependent
> > trees can be rebased and still not cause linux-next merge conflicts
> > (unless one of the tree changes causes conflicts with the patch set,
> > which you want to know about anyway).
> > The other drawback (or not depending on how you view rebases) is that
> > the postmerge tree has to be rebased on to the vanilla tree for
> > submission if any of its dependent trees got rebased.
> Hmm. This solves the "dependencies must be stable" problem by making
> everything on top unstable though. It makes it awkward for someone
> else to do downstream work from the tree, since they also have to
> rebase any time the dependency or the topic branch in our tree gets
> rebased. So we would end up with a cascade of rebases down the
> downstream trees.
You mean post-post merge trees? ... at least with SCSI, block and USB
we've never needed one of these beasts, to the problems you raise about
it are theoretical at best for us. But if we did, I assume someone
constructing that volatile a patch series be familiar with using git
like quilt (or simply use quilt).
> It sounds like it would fit well for the "linux-devel" type tree that
> Steven is proposing. But I think for linux-next we would be better off
> if we can reach a model that provides stable-by-default branches for
> dependent topics.
> Of course there might be cases where we truly need to do a rebase
> (say, for example, if Linus refuses to merge something), but if we
> handle things right it should be rare enough that it can be a manual
> event -- for us that has been the case so far.
Perhaps we should also have a topic on when to rebase? I know I rebase
a lot when either linux-next or the test projects find issues with
commits in the SCSI tree. It's a question of not breaking
bisectability. If you find a faulty commit and the tree hasn't yet gone
to Linus, I think it's better to fix it in situ causing a rebase but
preserving bisectability than it is to add an additional patch ... I
know there's opinion on the other side of this, though.
More information about the Ksummit-2012-discuss