[Qemu-devel] Unclear committer situation

[Qemu-devel] Unclear committer situation

[Alexander Graf]

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.

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.

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.

Alex

Re: [Qemu-devel] Unclear committer situation

[Anthony Liguori]

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.

> 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.

Regards,

Anthony Liguori

Re: [Qemu-devel] Unclear committer situation

[Blue Swirl]

On Tue, Dec 1, 2009 at 6:51 PM, Anthony Liguori <anthony@codemonkey.ws> 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.

Re: [Qemu-devel] Unclear committer situation

[Anthony Liguori]

Blue Swirl wrote:
>>> 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.
>   
Oh, no doubt.  I didn't mean to minimize the work that's gone into it.  
It's much better than it was a year ago.

Regards,

Anthony Liguori

Re: [Qemu-devel] Unclear committer situation

[Alexander Graf]

On 01.12.2009, at 19:51, Anthony Liguori 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.

It sounds like we're drawing different lines.

Maintainership for a subsystem is completely different from "feeling responsible for patches". You can be the person checking stuff in without knowing anything about the subsystem. If it breaks, have the community fix it. If it stays broken and nobody cares, remove the subsystem.

Alex

Re: [Qemu-devel] Unclear committer situation

[andrzej zaborowski]

2009/12/1 Alexander Graf <agraf@suse.de>:
> Maintainership for a subsystem is completely different from "feeling responsible for patches". You can be the person checking stuff in without knowing anything about the subsystem. If it breaks, have the community fix it. If it stays broken and nobody cares, remove the subsystem.

If it leads to removing the subsystem then it's not much gain for the
project and the users :)

I don't know of any succesful project that has maintainers who don't
feel responsible for the code they're comming.

Cheers

Re: [Qemu-devel] Unclear committer situation

[Alexander Graf]

andrzej zaborowski wrote:
> 2009/12/1 Alexander Graf <agraf@suse.de>:
>   
>> Maintainership for a subsystem is completely different from "feeling responsible for patches". You can be the person checking stuff in without knowing anything about the subsystem. If it breaks, have the community fix it. If it stays broken and nobody cares, remove the subsystem.
>>     
>
> If it leads to removing the subsystem then it's not much gain for the
> project and the users :)
>
> I don't know of any succesful project that has maintainers who don't
> feel responsible for the code they're comming.
>   

Well the point I was trying to make is that committer != maintainer. Avi
commits PPC/S390 kvm stuff all the time without knowing the
architectures inside out ;).

Alex

Re: [Qemu-devel] Unclear committer situation

[Avi Kivity]

On 12/02/2009 01:24 PM, Alexander Graf wrote:
>
>> If it leads to removing the subsystem then it's not much gain for the
>> project and the users :)
>>
>> I don't know of any succesful project that has maintainers who don't
>> feel responsible for the code they're comming.
>>
>>      
> Well the point I was trying to make is that committer != maintainer. Avi
> commits PPC/S390 kvm stuff all the time without knowing the
> architectures inside out ;).
>    

I always make a point of getting acks (or the patch itself) from someone 
who does.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Unclear committer situation

[Riku Voipio]

On Tue, Dec 01, 2009 at 12:51:25PM -0600, Anthony Liguori wrote:
>> 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.

I and Juha can take maintainence of the omap2 (and future omap3) stuff,
which obviously isn't mainted by anyone at the moment:

http://www.mail-archive.com/qemu-devel@nongnu.org/msg17487.html
http://lists.gnu.org/archive/html/qemu-devel/2009-06/msg00326.html

6 months for no action on a patch that fixes a "fails to boot" bug? No
wonder the android people have forked qemu so far...

> git pulls have been working really well for linux-user.  I'd like to  
> continue that for new architectures.

I can provide the patches in the same way as git pull requests.

Re: [Qemu-devel] Unclear committer situation

[Anthony Liguori]

Riku Voipio wrote:
>> git pulls have been working really well for linux-user.  I'd like to  
>> continue that for new architectures.
>>     
>
> I can provide the patches in the same way as git pull requests.
>   

Works for me.

Regards,

Anthony Liguori

Re: [Qemu-devel] Unclear committer situation

[Aurelien Jarno]

On Tue, Dec 01, 2009 at 12:47:36PM +0100, 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.
>
> 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.
>

I also try to follow the ppc architecture, though less than mips and
also depending on my free time. I know that Blue Swirl and Malc also
care about it.

It's not impossible that I miss patches given the current patches rate
on the mailing list, so don't hesitate to Cc: me. On the other hand, I
don't really feel comfortable with KVM related patches, I would prefer
to see them committed by Anthony.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] Unclear committer situation

[Alexander Graf]

On 02.12.2009, at 09:26, Aurelien Jarno wrote:

> On Tue, Dec 01, 2009 at 12:47:36PM +0100, 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.
>> 
>> 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.
>> 
> 
> I also try to follow the ppc architecture, though less than mips and
> also depending on my free time. I know that Blue Swirl and Malc also
> care about it.

Right - which makes it pretty hard. IMHO it's always best to have a single person to talk to when it comes to committing and others who comment on patches.

In fact, I even believe that the person committing stuff doesn't have to know the stuff he commits. If I make a patch that breaks S390 and someone commits it, it's my fault breaking it - not the committer's. If I do a patch breaking PPC KVM, it's my fault breaking it, not the committer's. And with fault I also mean "responsibility to fix".

> It's not impossible that I miss patches given the current patches rate
> on the mailing list, so don't hesitate to Cc: me. On the other hand, I
> don't really feel comfortable with KVM related patches, I would prefer
> to see them committed by Anthony.

Avi, can I get PPC KVM patches in through you then? I guess you're the closest person to the code in question.

Alex

Re: [Qemu-devel] Unclear committer situation

[Aurelien Jarno]

On Wed, Dec 02, 2009 at 09:37:16AM +0100, Alexander Graf wrote:
> 
> On 02.12.2009, at 09:26, Aurelien Jarno wrote:
> 
> > On Tue, Dec 01, 2009 at 12:47:36PM +0100, 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.
> >> 
> >> 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.
> >> 
> > 
> > I also try to follow the ppc architecture, though less than mips and
> > also depending on my free time. I know that Blue Swirl and Malc also
> > care about it.
> 
> Right - which makes it pretty hard. IMHO it's always best to have a single person to talk to when it comes to committing and others who comment on patches.

Some committers are not available for a long period of time. It also
happens to me.

> In fact, I even believe that the person committing stuff doesn't have to know the stuff he commits. If I make a patch that breaks S390 and someone commits it, it's my fault breaking it - not the committer's. If I do a patch breaking PPC KVM, it's my fault breaking it, not the committer's. And with fault I also mean "responsibility to fix".

Experience has shown that it doesn't work like that. It happens the
person writing the patches never provides a fix, and the committer
receives the complains, and in fine fixes the commit.

> > It's not impossible that I miss patches given the current patches rate
> > on the mailing list, so don't hesitate to Cc: me. On the other hand, I
> > don't really feel comfortable with KVM related patches, I would prefer
> > to see them committed by Anthony.
> 
> Avi, can I get PPC KVM patches in through you then? I guess you're the closest person to the code in question.
> 

If you an get your patches acked-by Avi, I am fine merging them.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] Unclear committer situation

[Alexander Graf]

On 02.12.2009, at 09:46, Aurelien Jarno wrote:

> On Wed, Dec 02, 2009 at 09:37:16AM +0100, Alexander Graf wrote:
>> 
>> On 02.12.2009, at 09:26, Aurelien Jarno wrote:
>> 
>>> On Tue, Dec 01, 2009 at 12:47:36PM +0100, 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.
>>>> 
>>>> 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.
>>>> 
>>> 
>>> I also try to follow the ppc architecture, though less than mips and
>>> also depending on my free time. I know that Blue Swirl and Malc also
>>> care about it.
>> 
>> Right - which makes it pretty hard. IMHO it's always best to have a single person to talk to when it comes to committing and others who comment on patches.
> 
> Some committers are not available for a long period of time. It also
> happens to me.

So we need a clear backup strategy. Something like that when you know you're not available for > 4 days, you assign someone else to be your replacement for that timeframe.

>> In fact, I even believe that the person committing stuff doesn't have to know the stuff he commits. If I make a patch that breaks S390 and someone commits it, it's my fault breaking it - not the committer's. If I do a patch breaking PPC KVM, it's my fault breaking it, not the committer's. And with fault I also mean "responsibility to fix".
> 
> Experience has shown that it doesn't work like that. It happens the
> person writing the patches never provides a fix, and the committer
> receives the complains, and in fine fixes the commit.

Then revert the patch. I also think we need to distinguish subsystems here.

So when you have something really core-y - like the main loop - then of course you go through a lot of review and try to get a lot of people involved, so it doesn't break.

On the other hand if you have a subsystem that is completely separate - like cris - you don't care if it's broken. If it is for > 24 hours, exclude it from the default build list. If you see that one person breaks stuff all along, tighten the restrictions for that person. But that doesn't mean all subsystems need a review as thorough as the core code.

In fact, it is a _lot_ easier to get code into Linux than it is to get it into Qemu. That's just plain wrong.

>>> It's not impossible that I miss patches given the current patches rate
>>> on the mailing list, so don't hesitate to Cc: me. On the other hand, I
>>> don't really feel comfortable with KVM related patches, I would prefer
>>> to see them committed by Anthony.
>> 
>> Avi, can I get PPC KVM patches in through you then? I guess you're the closest person to the code in question.
>> 
> 
> If you an get your patches acked-by Avi, I am fine merging them.

Cool, thanks!

Alex

Re: [Qemu-devel] Unclear committer situation

[Jan-Simon Möller]

Am Mittwoch 02 Dezember 2009 09:54:04 schrieb Alexander Graf:
> > 
> > Experience has shown that it doesn't work like that. It happens the
> > person writing the patches never provides a fix, and the committer
> > receives the complains, and in fine fixes the commit.
> 
> Then revert the patch. I also think we need to distinguish subsystems here.
Full ack on this - we have git, we can always revert without problem.

Make a policy like: at least another pair of eyes has to ack/sign-off and then lets commit it.
If a breakage occurs -> just revert, ppl will act.

> 
> So when you have something really core-y - like the main loop - then of course you go through a lot of review and try to get a lot of people involved, so it doesn't break.
> 
> On the other hand if you have a subsystem that is completely separate - like cris - you don't care if it's broken. If it is for > 24 hours, exclude it from the default build list. If you see that one person breaks stuff all along, tighten the restrictions for that person. But that doesn't mean all subsystems need a review as thorough as the core code.
> 
> In fact, it is a _lot_ easier to get code into Linux than it is to get it into Qemu. That's just plain wrong.

FWIW this is also my impression - IMHO we should adapt a similar process.


my 0.02 €  ... 

best,
Jan-Simon

Re: [Qemu-devel] Unclear committer situation

[Avi Kivity]

On 12/02/2009 10:37 AM, Alexander Graf wrote:
> On 02.12.2009, at 09:26, Aurelien Jarno wrote:
>
>    
>> On Tue, Dec 01, 2009 at 12:47:36PM +0100, 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.
>>>
>>> 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.
>>>
>>>        
>> I also try to follow the ppc architecture, though less than mips and
>> also depending on my free time. I know that Blue Swirl and Malc also
>> care about it.
>>      
> Right - which makes it pretty hard. IMHO it's always best to have a single person to talk to when it comes to committing and others who comment on patches.
>
> In fact, I even believe that the person committing stuff doesn't have to know the stuff he commits. If I make a patch that breaks S390 and someone commits it, it's my fault breaking it - not the committer's. If I do a patch breaking PPC KVM, it's my fault breaking it, not the committer's. And with fault I also mean "responsibility to fix".
>    

Breakage is simple.  This difficult stuff is keeping the code maintainable.

>    
>> It's not impossible that I miss patches given the current patches rate
>> on the mailing list, so don't hesitate to Cc: me. On the other hand, I
>> don't really feel comfortable with KVM related patches, I would prefer
>> to see them committed by Anthony.
>>      
> Avi, can I get PPC KVM patches in through you then? I guess you're the closest person to the code in question.
>    

Sure.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Unclear committer situation

[malc]

On Wed, 2 Dec 2009, Aurelien Jarno wrote:

> On Tue, Dec 01, 2009 at 12:47:36PM +0100, 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.
> >
> > 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.
> >
> 
> I also try to follow the ppc architecture, though less than mips and
> also depending on my free time. I know that Blue Swirl and Malc also
> care about it.

Just to clarify esp. taking into consideration first paragraph of 
Alexander's message, i do not care one bit about PPC target (not
until Alexander does something magical with PPC64 and i can continue
trying to resolve an old Linux's hard lockup issue). I do care about
PPC the host though.

> 
> It's not impossible that I miss patches given the current patches rate
> on the mailing list, so don't hesitate to Cc: me. On the other hand, I
> don't really feel comfortable with KVM related patches, I would prefer
> to see them committed by Anthony.
> 
> 

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Unclear committer situation

[Artyom Tarasenko]

2009/12/1 Alexander Graf <agraf@suse.de>:
> 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.

And who can increase chances of getting committed for a scsi-related patch?
I sent a patch on November, the 10th (http://patchwork.ozlabs.org/patch/38100/),
and it looks like it was just ignored.

[Qemu-devel] Re: Unclear committer situation

[Jan Kiszka]

Artyom Tarasenko wrote:
> 2009/12/1 Alexander Graf <agraf@suse.de>:
>> 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.
> 
> And who can increase chances of getting committed for a scsi-related patch?
> I sent a patch on November, the 10th (http://patchwork.ozlabs.org/patch/38100/),
> and it looks like it was just ignored.
> 

Patch is line-wrapped (following your link to patchwork makes this obvious).

Note that the merge process can be quite silent. Hearing nothing for a
while (some weeks) may also mean that your patch suddenly pops up in the
tree - given it's clean and no one complained.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: Unclear committer situation

[Artyom Tarasenko]

2009/12/2 Jan Kiszka <jan.kiszka@siemens.com>:
> Artyom Tarasenko wrote:
>> 2009/12/1 Alexander Graf <agraf@suse.de>:
>>> 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.
>>
>> And who can increase chances of getting committed for a scsi-related patch?
>> I sent a patch on November, the 10th (http://patchwork.ozlabs.org/patch/38100/),
>> and it looks like it was just ignored.
>>
>
> Patch is line-wrapped (following your link to patchwork makes this obvious).

Oh. Can it be that a simultaneous inlining and attachment
(what Blue Swirl suggested few weeks ago) is not compatible with patchwork?

The patch in the attachment doesn't seem to be line-wrapped.

Will have to find a way to persuade gmail not to wrap patches.

> Note that the merge process can be quite silent. Hearing nothing for a
> while (some weeks) may also mean that your patch suddenly pops up in the
> tree - given it's clean and no one complained.

Already experienced that too. :)

[Qemu-devel] Re: Unclear committer situation

[Michael S. Tsirkin]

On Wed, Dec 02, 2009 at 07:48:04PM +0100, Artyom Tarasenko wrote:
> Will have to find a way to persuade gmail not to wrap patches.

gmail MSA/MTA does not wrap patches IMO. the web interface
does and IMO can not be told not to, so just find another MUA you like
to send mail.

-- 
MST

Re: [Qemu-devel] Re: Unclear committer situation

[andrzej zaborowski]

2009/12/3 Michael S. Tsirkin <mst@redhat.com>:
> On Wed, Dec 02, 2009 at 07:48:04PM +0100, Artyom Tarasenko wrote:
>> Will have to find a way to persuade gmail not to wrap patches.
>
> gmail MSA/MTA does not wrap patches IMO. the web interface
> does and IMO can not be told not to, so just find another MUA you like
> to send mail.

There's the Show original link when viewing emails that always works
for me when applying patches, although attachment is asier to deal
with so both an inline copy for review and attachment should satisfy
everyone.

Cheers

Re: [Qemu-devel] Re: Unclear committer situation

[Anthony Liguori]

Jan Kiszka wrote:
> Artyom Tarasenko wrote:
>   
>> 2009/12/1 Alexander Graf <agraf@suse.de>:
>>     
>>> 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.
>>>       
>> And who can increase chances of getting committed for a scsi-related patch?
>> I sent a patch on November, the 10th (http://patchwork.ozlabs.org/patch/38100/),
>> and it looks like it was just ignored.
>>
>>     
>
> Patch is line-wrapped (following your link to patchwork makes this obvious).
>
> Note that the merge process can be quite silent.

Actually, I provided this feedback for the first submission.  He 
resubmitted again with the same issue.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: Unclear committer situation

[Artyom Tarasenko]

2009/12/2 Anthony Liguori <anthony@codemonkey.ws>:
> Jan Kiszka wrote:
>>
>> Artyom Tarasenko wrote:
>>
>>>
>>> 2009/12/1 Alexander Graf <agraf@suse.de>:
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> And who can increase chances of getting committed for a scsi-related
>>> patch?
>>> I sent a patch on November, the 10th
>>> (http://patchwork.ozlabs.org/patch/38100/),
>>> and it looks like it was just ignored.
>>>
>>>
>>
>> Patch is line-wrapped (following your link to patchwork makes this
>> obvious).
>>
>> Note that the merge process can be quite silent.
>
> Actually, I provided this feedback for the first submission.  He resubmitted
> again with the same issue.

All you have said was "the patch is whitespace damaged". Does it mean
the same as
"Attaching everything as "application/octet-stream" is broken"? No.
There are multiple possible ways to be whitespace damaged. I assumed
the problem had to do with the tabs vs. spaces issue and asked a
question how to deal with that. Did anyone answer? No.
Blue suggested that you pointed out that one of new lines in the patch
was longer than 80 characters. I fixed it and re-submitted. Did anyone
say "still broken the same way"? No.
I didn't know that there are so many commiters that providing a two
sentences response is already a huge overhead for the maintainers.
Sorry.

Artyom

P.S. All my previous patches were also sent through gmail and
inlined+attached as "application/octet-stream". Somehow it didn't make
problems before.

Re: [Qemu-devel] Unclear committer situation

[Anthony Liguori]

Artyom Tarasenko wrote:
> 2009/12/1 Alexander Graf <agraf@suse.de>:
>   
>> 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.
>>     
>
> And who can increase chances of getting committed for a scsi-related patch?
> I sent a patch on November, the 10th (http://patchwork.ozlabs.org/patch/38100/),
> and it looks like it was just ignored.
>   

It's still whitespace damaged.  Attaching a second copy as an 
application/octet does not make the situation any better.  Take the time 
to send the patch properly and someone will take the time to 
review/apply it. 

Regards,

Anthony Liguori

Re: [Qemu-devel] Unclear committer situation

[Artyom Tarasenko]

2009/12/2 Anthony Liguori <anthony@codemonkey.ws>:
> Artyom Tarasenko wrote:
>>
>> 2009/12/1 Alexander Graf <agraf@suse.de>:
>>
>>>
>>> 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.
>>>
>>
>> And who can increase chances of getting committed for a scsi-related
>> patch?
>> I sent a patch on November, the 10th
>> (http://patchwork.ozlabs.org/patch/38100/),
>> and it looks like it was just ignored.
>>
>
> It's still whitespace damaged.  Attaching a second copy as an
> application/octet does not make the situation any better.  Take the time to
> send the patch properly and someone will take the time to review/apply it.

I thought attaching a second copy were the way to send the patch properly.
Is the proper way described somewhere?

Re: [Qemu-devel] Unclear committer situation

[Alexander Graf]

On 02.12.2009, at 19:53, Artyom Tarasenko wrote:

> 2009/12/2 Anthony Liguori <anthony@codemonkey.ws>:
>> Artyom Tarasenko wrote:
>>> 
>>> 2009/12/1 Alexander Graf <agraf@suse.de>:
>>> 
>>>> 
>>>> 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.
>>>> 
>>> 
>>> And who can increase chances of getting committed for a scsi-related
>>> patch?
>>> I sent a patch on November, the 10th
>>> (http://patchwork.ozlabs.org/patch/38100/),
>>> and it looks like it was just ignored.
>>> 
>> 
>> It's still whitespace damaged.  Attaching a second copy as an
>> application/octet does not make the situation any better.  Take the time to
>> send the patch properly and someone will take the time to review/apply it.
> 
> I thought attaching a second copy were the way to send the patch properly.
> Is the proper way described somewhere?

From experience the easiest for everyone (at least the readers) is git-format-patch and git-send-email.

Alex

Re: [Qemu-devel] Unclear committer situation

[Filip Navara]

On Wed, Dec 2, 2009 at 7:56 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 02.12.2009, at 19:53, Artyom Tarasenko wrote:
>
>> 2009/12/2 Anthony Liguori <anthony@codemonkey.ws>:
>>> Artyom Tarasenko wrote:
>>>>
>>>> 2009/12/1 Alexander Graf <agraf@suse.de>:
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> And who can increase chances of getting committed for a scsi-related
>>>> patch?
>>>> I sent a patch on November, the 10th
>>>> (http://patchwork.ozlabs.org/patch/38100/),
>>>> and it looks like it was just ignored.
>>>>
>>>
>>> It's still whitespace damaged.  Attaching a second copy as an
>>> application/octet does not make the situation any better.  Take the time to
>>> send the patch properly and someone will take the time to review/apply it.
>>
>> I thought attaching a second copy were the way to send the patch properly.
>> Is the proper way described somewhere?
>
> From experience the easiest for everyone (at least the readers) is git-format-patch and git-send-email.

If only everything was as easy as it sounds. Unfortunately
git-send-email was for long time unavailable to Windows users and even
now it is barely usable and hard to configure. TortoiseGit once again
doesn't work because of the changed setting on the nongnu.org mail
server... For me it is never-ending battle, instead of working on QEMU
I have to "fix" the GIT tools to send the patches properly each time I
want to send a patch.

Best regards,
Filip Navara

Re: [Qemu-devel] Unclear committer situation

[Anthony Liguori]

Filip Navara wrote:
> If only everything was as easy as it sounds. Unfortunately
> git-send-email was for long time unavailable to Windows users and even
> now it is barely usable and hard to configure. TortoiseGit once again
> doesn't work because of the changed setting on the nongnu.org mail
> server... For me it is never-ending battle, instead of working on QEMU
> I have to "fix" the GIT tools to send the patches properly each time I
> want to send a patch.
>   

Unfortunately, developing on Windows is going to be difficult because 
the vast majority of developers are on Unix platforms.

If there's something we can do to make that better, I'm all for it, but 
git's been a huge win for us.  We simply couldn't support the volume of 
patches we do today without it.

Regards,

Anthony Liguori

Re: [Qemu-devel] Unclear committer situation

[Anthony Liguori]

Artyom Tarasenko wrote:
> I thought attaching a second copy were the way to send the patch properly.
>   

Attaching as an application/octet-stream is not terribly helpful.  It 
basically means you've attached a binary blob.

> Is the proper way described somewhere?
>   

The proper way is to use a mailer that isn't broken.  Attaching 
everything as "application/octet-stream" is broken.

Regards,

Anthony Liguori

Re: [Qemu-devel] Unclear committer situation

[Riku Voipio]

On Wed, Dec 02, 2009 at 01:12:30PM -0600, Anthony Liguori wrote:
> Artyom Tarasenko wrote:
>> I thought attaching a second copy were the way to send the patch properly.

> Attaching as an application/octet-stream is not terribly helpful.  It  
> basically means you've attached a binary blob.

>> Is the proper way described somewhere?

> The proper way is to use a mailer that isn't broken.  Attaching  
> everything as "application/octet-stream" is broken.

That should be reported to google.. more and more developers are using gmail
or google hosting for their company mail. Simply switching to another mailer
may not be as easy as it sounds.

Re: [Qemu-devel] Unclear committer situation

[Carl-Daniel Hailfinger]

On 02.12.2009 20:12, Anthony Liguori wrote:
> Artyom Tarasenko wrote:
>> I thought attaching a second copy were the way to send the patch
>> properly.
>>   
>
> Attaching as an application/octet-stream is not terribly helpful.  It
> basically means you've attached a binary blob.
>
>> Is the proper way described somewhere?
>>   
>
> The proper way is to use a mailer that isn't broken.  Attaching
> everything as "application/octet-stream" is broken.

Some mailers do the right thing if the attachment name ends in .txt
(maybe that helps with gmail).

Regards,
Carl-Daniel

-- 
Developer quote of the month: 
"We are juggling too many chainsaws and flaming arrows and tigers."

[Qemu-devel] Re: Unclear committer situation

[Michael S. Tsirkin]

On Thu, Dec 03, 2009 at 01:56:57PM +0100, Carl-Daniel Hailfinger wrote:
> On 02.12.2009 20:12, Anthony Liguori wrote:
> > Artyom Tarasenko wrote:
> >> I thought attaching a second copy were the way to send the patch
> >> properly.
> >>   
> >
> > Attaching as an application/octet-stream is not terribly helpful.  It
> > basically means you've attached a binary blob.
> >
> >> Is the proper way described somewhere?
> >>   
> >
> > The proper way is to use a mailer that isn't broken.  Attaching
> > everything as "application/octet-stream" is broken.
> 
> Some mailers do the right thing if the attachment name ends in .txt
> (maybe that helps with gmail).


linux documentation suggests firefox extension ViewSourceWith.

Re: [Qemu-devel] Unclear committer situation

[Isaku Yamahata]

BTW what happened to qemu-commit?
It deosn't seem to be working.

On Tue, Dec 01, 2009 at 12:47:36PM +0100, 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.
>
> 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.
>
> 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.
>
> Alex
>
>
>
>

-- 
yamahata