On Tue, Mar 13, 2012 at 01:01, Andreas Färber <afaer...@suse.de> wrote: > Am 13.03.2012 01:16, schrieb Anthony Liguori: >> On 03/12/2012 06:32 PM, Andreas Färber wrote: >>> Take Blue's recent target-ppc fix >>> 9d4df9c02866f39d3eef105033091f367cc7c29e for example: After applying >>> patches on day one of FOSDEM he posted a -Werror fix, it got confirmed >>> by me and Alex but wasn't applied until a week later, because apparently >>> no other committer dared to apply Blue's patch despite SoB and acks and >>> people reporting the issue... Not happy. >>> No doubt Alex is to blame for not catching that issue in his ppc queue, >>> but asking Alex as submaintainer to submit a PULL for a single patch >>> posted by Blue as committer seems overly complicated to me! ;) >> >> I think this is a good demonstration of what the problem is. Unclear >> responsibility. > > Agreed. Solution is documentation of expected workflows. > >> I'm pretty sure that Blue thought that Alex would >> handle the patch. I'm pretty sure that Alex thought Blue would handle >> the patch. > > Alex actually asked Blue to. > > However from what I understand, Blue is not working on QEMU full-time, > like me previously. I assume he handled the patch once he read and came > around to it. It's just that no one else with commit powers reacted to > the situation.
Real life can be pretty demanding at times. I can't imagine when I would mind if somebody else applied patches I've sent if they are not RFC. > The way I see it no one "owns" code in QEMU. Some people feel > responsible for (or comfortable reviewing changes to) parts of QEMU, and > the project scales by distributing review, testing and queuing to more > such shoulders. > However where a (sub)maintainer is unresponsive - and *there* I > differentiate between build breakages, runtime issues and feature > additions - we can't wait forever and need to adapt processes. Fixing > the build within a reasonable time is one requirement, moving forward > with target-mips at all is another example. > > It's not really that we have too few maintainers, it's that not all > maintainers maintain at all times - for valid work or personal reasons - > and we don't seem to have a well-working escalation mechanism beyond > ping^n to handle that. This particular issue could have been avoided with more thorough compile testing by me before pushing Alex's PPC tree, or by Alex himself before submitting d1e256fe. > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
