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

James Bottomley James.Bottomley at HansenPartnership.com
Mon Jun 18 07:36:44 UTC 2012

On Sun, 2012-06-17 at 15:32 -0700, Olof Johansson wrote:
> Hi,
> On Sun, Jun 17, 2012 at 12:45 PM, Mark Brown <broonie at sirena.org.uk> wrote:
> >  - General process and tooling issues, especially around the things that
> >   come up in the embedded area where there's a bunch of things like
> >   like lots of cross tree dependencies which seem to be driving new
> >   processes like the arm-soc ones with dependency branches.  Do we want
> >   to roll these things out more broadly?
> >
> >   There are (as ever) a bunch of pain points at all levels, not that
> >   I've got any particularly bright ideas about most of them.
> The cross-tree dependencies have been a little rocky on arm-soc, with
> a couple of pretty hairy lessons learned. It's working better and
> better over time though.
> For those who aren't aware of what it is: It's common that we see
> patches that do the platform-side changes needed for driver updates or
> some other subsystem change. While we could just ack the
> arch/arm/mach* side change for it and let it go in through the other
> subsystem tree, we have in the past had some messy merge conflicts
> caused by it since the arch/arm code sees a lot of updates due to
> consolidation, etc.
> So we've started to ask our subarch maintainers to provide a stable
> branch with the other subsystem changes, such that we can pull it in
> as a base for their changes.
> There's a couple of gotchas of course.
> 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.


More information about the Ksummit-2012-discuss mailing list