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

[Mark Brown]

On Sun, Jun 17, 2012 at 03:32:05PM -0700, Olof Johansson wrote:

> There's a couple of gotchas of course.

The other one you haven't mentioned but which I've started to see a few
times is that it's causing some of the submaintainers to become very
lazy about their topic branches and keeping things split since they
figure they can just throw everything at arm-soc.  That's just a general
education thing, but it's another thing on the list of things to watch
out for.

> 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

I never entirely understood why you do that, it just seems to make
everything more complex.  From the point of view of publishing things if
I've published something for cross merging then it's static and it's as
much a part of any other tree it gets merged into as the "origin" tree.
It'd make sense if you were rebasing onto the other tree but if you're
not.  Is it just for catching rebased dependencies or is there more to
it?

> 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.

Isn't the only issue there the waiting for the other tree to merge?
Plus thinking of a sensible reason to come up with something like that
of course.

> 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.

Personally I think that if we're going to follow this sort of model
(mainly with the blocking the merges bit) we should just do it as a
general workflow thing and not make it specific to ARM - there's not
really anything ARM-specific about it but there is a bunch of scripting
and monitoring which can usefully be centralised.  The same thing comes
up quite a lot for the lower level APIs where they're being extended,
some of the examples I've seen already were really examples of people
wanting to do this.