[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable
olof at lixom.net
Tue Jun 19 07:42:42 UTC 2012
On Mon, Jun 18, 2012 at 3:03 AM, Mark Brown <broonie at sirena.org.uk> wrote:
> 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.
Agreed. I think some of the general work flow has started changing too
-- in the past it was more common to get the infrastructure in the
release before, then the users the next release. Now we're trying to
get both of them in through the same merge window. It means that work
can progress at a quicker pace but it also adds some complexity as
>> > 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.
We're learning as we go along, and I think we've been tweaking it for
every release so far. This thread has been great w.r.t. things we
> 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.
Yes, I think we're all in agreement that having blocking dependencies
isn't going to scale.
>> - 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
Sounds good to me. We'll start small on this as we add dependencies
for 3.6 (we don't have any yet), and take it from there.
More information about the Ksummit-2012-discuss