Is there a core group/committee that handles all fixes, code, and what not?
On 3/12/12, Alexander Graf <ag...@suse.de> wrote: > > > Am 13.03.2012 um 02:01 schrieb Andreas Färber <afaer...@suse.de>: > >> 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. >> >> 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. > > Let's take a real world example from Linux here. 3.3-rc5 had a pretty nasty > compile bug that made the build break on any 32 bit target when autofs was > activated. I posted the bug plus a small bugfix upstream. > > What happened? Linus went ahead and fixed the thing properly so rc6 could go > out quickly. > > I guess that's what Andreas is trying to say here. Making sure new stuff > works, fixing uncritical bugs etc is well within a maintainer's > responsibility. Keeping all the code together is where it boils down to the > next, the global level, the comitters. > > That doesn't mean that any of this is exclusive, but it means that whoever > works on the global scale of the project - and that's what commit rights > mean - is oblidged to care about the wellbeing of the whole project as a > whole. You can't just pick a few subsystems and say "I maintain QEMU but I > don't care if SH4 breaks". That'd be hypocritical :). The same way I can't > say "This is a patch in PPC code but because this is a particular > implementation I don't care about I'll ignore it". > > Unfortunately - mainly for historical and political reasons - that subsytem > thinking happens a lot in QEMU land these days. And I'm not sure how to > change that. Few people actually care about all aspects of QEMU at the same > time. > > > Alex > > >
