Patchwork (was Re: Governance revisited)

[Ge van Geldorp]

> From: Vitaliy Margolen <wine-devel at kievinfo.com>
> 
> So in a sense you will require some one to respond for any 
> incoming e-mail to wine-patches. And if no one does, 
> Alexandre don't get to see the status?

Not sure I understand what you mean. If no-one responds to the patch on
wine-devel the patch would remain queued and it would show up in Alexandres
list.

> What if he already 
> applied the patch? Now you slowing down what would have 
> worked just fine before.

If the patch is already applied it would be marked as such in the database.
When a message is sent to wine-devel after the fact, it won't get magically
un-applied.

> Ok now you making it dependant on an e-mail client. Yet 
> that's exactly what we are trying avoid with GIT.

Actually, my preference would be to do patch management via a web-based
interface. But that's just my preference, I assume a lot of other people
prefer the mailinglist method. So let's try to support both.

> Not really. You can't make some one to review something that 
> don't understand. Or if they are busy/on vacation/away from 
> PC/etc.

I'm not trying to change the review process, it would remain as-is. The only
addition would be a bot which could do some checks (e.g. does the patch
apply cleanly?). But that bot could be introduced anyway, even if Patchwork
isn't introduced, so I guess it's not an integral part of the proposed
system.

> So in the end you'll end up with either huge queue 
> that no one wants to touch. Or a "clean up" jobs that will 
> once in a while go and mark all patches as old and will 
> require authors to resubmit. How's that better then what we use now?

If no-one touches a patch, it would end up on Alexandres plate. He could
review the patch himself or ask a subsystem maintainer to review it. Again,
that's not different from the current system. If the queue of patches
waiting for commit grows without bounds, that's a clear indication that
Alexandre is overloaded and the project should find ways to remove some of
his workload. The same would happen without a patch management system, but
perhaps it wouldn't be as visible, so I'm chalking this one up as an added
benefit of a patch management system.
The system would also be self-cleaning. If a patch has been in RFC status
too long it would be deleted from the queue (with appropriate warning email
to the author)
http://www.winehq.org/pipermail/wine-devel/2006-September/051114.html

> When people well send out right hacks and expect some one to 
> tell then what they really should do. Current system allows 
> to no waste any time on such craft.

We seem to have fundamentally different views of the "peripheral" (non-core)
Wine developers. You seem to view them as potentially bad guys, going out of
their way to submit hacks and decrease the quality of Wine code as much as
possible, people you'd rather see leave. I see people willing to donate
their time to improve Wine. Sure, they make mistakes but at least they make
an effort.

> No, by requiring some one to respond you making them 
> responsible (at least until they respond). Of course 
> responses like "sucks" wouldn't be nice, so some one who does 
> understand the subject will have to spend their time to 
> understand the patch, write a review of the patch and send 
> it.

I don't get your point here. Isn't the purpose of reviewing to actually
review the patch?

> And you want that ASAP! Which means whenever patch 
> arrives in wine-patches some one (most likely more then one 
> person) will stop everything they are doing, and start 
> writing a review?

No, I don't want to change the review process. It can remain just as it is
now.

My objective is to improve Wine by maximizing the number of patches of
acceptable quality. In my opinion, this can be done by:

1) assuring no patches get lost
2) assuring an author gets informed about why his patch is not acceptable in
its current form so he can improve it.

Ge van Geldorp.