qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Unclear committer situation


From: Blue Swirl
Subject: Re: [Qemu-devel] Unclear committer situation
Date: Tue, 1 Dec 2009 19:21:28 +0000

On Tue, Dec 1, 2009 at 6:51 PM, Anthony Liguori <address@hidden> wrote:
> Alexander Graf wrote:
>>
>> Hi,
>>
>> Could someone with commit rights please stand up to feel responsible for
>> PPC?
>>
>> Usually, when I send a patch to qemu-devel, I know who to address to
>> increase chances of it getting committed. For kvm/vnc/block I just CC
>> Anthony, for Audio I just CC malc, etc.
>>
>> There are some subsystems where nobody feels responsible though,
>> apparently hoping 'someone else' will tske on it. Well, turns out it doesn't
>> work that way.
>
> The general problem is that someone has to step up to maintain these
> subsystems.  For some of them, there just isn't really a lot of interest.

Getting a decent test setup for each architecture is a bit of work too.

>> So could we please assign a committer for every subsystem around? Even if
>> the committer doesn't know the architecture inside out, it's still valuable
>> to have soneone feel responsible at all. Committer and maintainer also don't
>> have to be the same person. I'll gladly maintain S390 without having commit
>> rights - as long as I have someone to CC and know the patches will get
>> merged.
>
> git pulls have been working really well for linux-user.  I'd like to
> continue that for new architectures.
>
>> Of course, my main unclear subsystems are PPC and S390.
>>
>> I'd recommend the following committers:
>>
>> PPC: Blue Swirl
>> S390: Aurelien
>>
>> If you have other subsystems you feel uncertain on responsibilities,
>> please add them to the list incl. committer recommendation.
>
> PPC is tough because we lost our previous maintainer.  It's generally in
> pretty bad shape.  No one really has stepped up to seriously improve it
> either.

The design approach was often different from other architectures,
which makes things like qdev conversion less trivial (see macio.c).
Otherwise IMHO the situation has improved a lot, we even have a
working BIOS. Only PREP has rotten.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]