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

Olof Johansson olof at lixom.net
Sun Jun 17 22:32:05 UTC 2012


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.

The flip side is that this might not flow well with how some other
subsystems are maintained today -- some maintainers like to keep a
fairly open for-next branch that they later rebase and cull patches
from closer to the merge window. That obviously won't work well for
us. In some of those cases, having two branches (a for-next that's
mostly open, and a "stable" for-next that has the patches that are now
set in stone) would solve it, but some people might have reasons to
not work that way?

And finally, of course, another drawback is that we're held up from
sending in our branches that contain the dependency until the other
subsystem pull request has landed. We also have to be careful about
cyclical dependencies -- so far that has not been a problem for us
since no one else has pulled in arm-soc branches at their end.

Anyway, that's where we're at on our use of that model. It seems to be
working well for us right now, but it does require a bit of extra
handshakes when we pull in a dependency (to make 100% sure the other
maintainer knows what it means for him). We're definitely open for
suggestions on how to solve it in a better way, if there is one.


More information about the Ksummit-2012-discuss mailing list