Re: Governance revisited

[Ge van Geldorp]

> From: Steven Edwards
>
> Which is why we want to have the ambassadors project to help 
> new people in to wine. The thinking goes that if we have some
> people to help hold the hands of new developers and the
> developers that are defacto maintainers of a certain section
> of code will respond to patches as they seem them, this will
> free julliard from having to answer every single patch with a 
> reply.

You can have ambassadors and subsystem maintainers all you want, but in the
end it's still going to be Alexandre who decides if a patch goes in. That
means the end-responsibility of informing developers why a patch was
rejected needs to be with Alexandre. If an ambassador or subsystem
maintainer already explained it, fine, no need to create double work for
Alexandre, but if noone responded I'd still expect Alexandre to send a
notification.

Just for the record, my own policy on patch submission (and I really hope to
get back to working on Wine and submitting patches Real Soon Now :-)) is to
submit a patch once. If I get feedback I'll try to improve and resubmit, but
if it goes the black hole route I'm not going to beg for an explanation. If
the Wine community can't be bothered to provide feedback I can't be bothered
to resubmit. After all, I've already scratched my itch, the bug is already
fixed in my tree, it's the communities loss, not mine.

Ge van Geldorp

Governance revisited

[Robert Lunnon]

On Monday 25 September 2006 20:08, Ge van Geldorp wrote:
> > From: Steven Edwards
> >
> > Which is why we want to have the ambassadors project to help
> > new people in to wine. The thinking goes that if we have some
> > people to help hold the hands of new developers and the
> > developers that are defacto maintainers of a certain section
> > of code will respond to patches as they seem them, this will
> > free julliard from having to answer every single patch with a
> > reply.
>
> You can have ambassadors and subsystem maintainers all you want, but in the
> end it's still going to be Alexandre who decides if a patch goes in. That
> means the end-responsibility of informing developers why a patch was
> rejected needs to be with Alexandre. If an ambassador or subsystem
> maintainer already explained it, fine, no need to create double work for
> Alexandre, but if noone responded I'd still expect Alexandre to send a
> notification.
>
> Just for the record, my own policy on patch submission (and I really hope
> to get back to working on Wine and submitting patches Real Soon Now :-)) is
> to submit a patch once. If I get feedback I'll try to improve and resubmit,
> but if it goes the black hole route I'm not going to beg for an
> explanation. If the Wine community can't be bothered to provide feedback I
> can't be bothered to resubmit. After all, I've already scratched my itch,
> the bug is already fixed in my tree, it's the communities loss, not mine.

This mirrors my policy, I used to care - now I don't - That is bad, Wine needs 
developers who care.

(Patently I do care enough to start this thread)
Also the ambassador program doesn't help to improve the process , it serves to 
perpetuate it.

Bob
> Ge van Geldorp