[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable
neilb at suse.de
Wed Jun 20 22:52:21 UTC 2012
On Tue, 19 Jun 2012 10:34:00 +0100 James Bottomley
<James.Bottomley at HansenPartnership.com> wrote:
> 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.
It sounds to me like people are finding ways to work around process issues
with a platform that "we" own and control.
Is this an instance of "The platform problem"?
Can we suggest enhancements to 'git' that would make these problems disappear?
e.g. A common problem is that a bug is found in a patch that is already
sufficiently 'frozen' that we would rather not fix it in-situ, but we want
the patch which fixes the bug to be tightly bound to the patch which
introduces the bug - sufficiently tightly that 'git bisect' will prefer not
to separate them.
If the 'fix' commit is created so that it's parent is the 'break' commit, we
would just need some tag in the 'fix' commit to say "Always include me with
my parent if possible". Then we would need some smarts in git-bisect to
honour this tag.
I suspect those smarts would be very non-trivial, but then the issue that is
being addressed is very prevalent so it is probably worth it (easy for me to
say as I'm not doing the coding).
And having 'fixes bug in XX' as a machine-readable annotation would
doubtlessly have other benefits.
i.e. should we be looking at how to enhance the tool instead of (or as well
as) how to enhance the process?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 828 bytes
Desc: not available
More information about the Ksummit-2012-discuss