[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable
broonie at sirena.org.uk
Mon Jun 18 10:03:58 UTC 2012
On Sun, Jun 17, 2012 at 05:03:49PM -0700, Olof Johansson wrote:
> 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.
Possibly it might for ARM but it's a general ongoing need for lower
level APIs - you add a new feature, people want to use it without
waiting for the next merge window and so this comes up.
> > 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.
Yes, this is why I found your workflow to be very odd - it's adding
complexity and fragility to the process. As you know I'm already
getting regular issues getting things into arm-soc due to to process
issues with getting stuff in through your submaintainers and this seems
to be creating additional variations on the same theme, plus creating
more work for you guys tracking all the dependencies.
> - Another alternative is the other maintainer signing a tag
> appropriately in the topic branch and indicating their agreement that
> 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.
I'd tend to do the signed tag, partly because of the description thing
and partly because it's the same process we use with Linus anyway. It
just generally seems like the obvious thing to do, though obviously just
normal pull requests work too. It's what I've done when people are
pulling in my stuff, though so far it's mostly been me merging my own
code and I generally find I can trust myself not to do things I find too
annoying. It'd never have occurred to me to do anything different to be
More information about the Ksummit-2012-discuss