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

Olof Johansson olof at lixom.net
Mon Jun 18 00:03:49 UTC 2012


On Sun, Jun 17, 2012 at 4:10 PM, Mark Brown <broonie at sirena.org.uk> wrote:
> 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.

Agreed, and it's something we should get better at spotting at our end
when said (non-arm) patches show up, to either make sure they have
proper acks, or that they get broken out in separate dependent topics.
Feel free to yell at us (and the originator) if we slip up.

I would hope that the amount of cross-dependent development should go
down over time as things settle down -- device-tree should mean less
platform_data modifications at both ends, and so on. But some of it is
probably part of the new normal now that ARM platforms have moved
their drivers out of their sandboxes.

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

Personally it's mostly to be polite, and let whomever maintains the
other part of the kernel push in his own changes. We have started
asking if it's OK that it gets merged through arm-soc if we get our
pull requests out first (Arnd arranged for one of the dependencies for
3.5 that way), and we can easily move to that model on a
per-dependency basis if needed.

Rebased dependencies can be caught on either side, and normally
Stephen is the one who starts yelling when they show up since they
make his life hell.

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

Agreed, with an agreement that either merge path is OK, cyclical
dependencies (between trees) shouldn't be a problem.

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

If this is to scale, then coming up with a non-blocking work flow is
likely a must -- it will quickly get messy otherwise. Another, more
important part is that someone can hold other maintainers hostage if
they for some reason don't get their pull requests done with time to
spare in the merge window.

A mostly common protocol for these things makes sense. It needs to be
super-light-weight though. A few options:

- Nothing stops us from adding Acked-by tags in merge commits. An
acked-by of the merge by the other subsystem maintainer could be a
good way to indicate that the he/she is OK with this topic landing
upstream through either tree first, since the contents is in both.
- Another alternative is the other maintainer signing a tag
appropriately in the topic branch and indicating their agreement that
way.

Or, maybe even those are overly complicated and the current
arrangement with just an email going back and forth saying "yup, ok
with me" between the maintainers is adequate.

I'm partial to the signed tag approach myself, it's really convenient
to pull signed tags with descriptions and there's no doubt who they
came from later on.


-Olof


More information about the Ksummit-2012-discuss mailing list