[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable

Olof Johansson olof at lixom.net
Tue Jun 19 08:02:26 UTC 2012

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.

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.


More information about the Ksummit-2012-discuss mailing list