From: Vitaliy Margolen wine-devel@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.