Patchwork (was Re: Governance revisited)

[Troy Rollo]

On Thursday 28 September 2006 05:49, Mike McCormack wrote:

> Seems like that is a system that doesn't scale well at all, as it
> requires Alexandre to specifically respond to each and every patch.

He still has to take an action to review each patch now, and presumably some 
action to remove it from his queue (speculation since we don't have his 
process documented - which is why I asked if we could get a vncrec file 
showing a patch reveiew/application/rejection session, so I could document 
it). If the process fits into this workflow without disruption the cost 
should actually be less since it saves having a conversation about why the 
patch was rejected.

> It also seems like it encourages patch submitters to not polish their
> patches themselves and just submit a higher volume of low quality
> patches for Alexandre to review, since the onus will then be on him to
> respond.

You seem to be assuming people are submitting patches they *know* will not be 
accepted (discounting ones submitted for the purposes of record only where 
the submitter says they don't expect it to be committed). This would be 
pathological behaviour since it would require more work on the part of the 
submitter as well as on the part of Alexandre. In fact the present process is 
likely to involve more work since it requires people to speculate about why 
the patch was rejected or passed over, and if they get it wrong, resubmit. 
Often there wasn't even anything wrong in the first place (the "oops" 
bitbucket) so all the speculation and rework will be a pointless exercise. If 
the patch is reworked, it's submitted again, has to be reviewed again, wait, 
rinse, repeat. That will result in more patches than if people are told the 
actual (rather than speculative) reason it was not applied.

> The current system, which leaves the responsibility for the patch with
> the submitter both scales better, and encourages patch submitters to
> think about their patches more.

(the following sounds somewhat harsher than it's intended to but I couldn't 
figure out a better way to say it)

If you can call speculation thinking, but I don't know what you mean by scales 
better. Speculative review increases the chance that Alexandre has to spend 
time reviewing more wrong patches because other people guessed wrong. The 
current system has literally cost me tens of thousands of dollars in wasted 
developer time on just a handful of patches (not including time I have wasted 
on it personally), so if by "scales better" you mean "passes off a relatively 
small cost off (sometimes without actually removing that cost) to others 
magnified by huge factors" then yes I guess it does "scale better", but 
scaling up the expense doesn't seem to be a good idea to me. Maybe some other 
employers don't mind throwing money away like this (Jeremy?), but I do.

> Responding to each and every patch seems like it would be a waste of
> Alexandre's time.  We should encourage more people to participate in the
> patch review process, so that we have more reviewers and a more scalable
> process.

It's more of an heuristic than a determinitive process unless the reviewers 
know for certain Alexandre's reasons for rejecting a patch (assuming an 
unapplied patch has in fact been rejected), which requires either telepathy 
or that he tell them.

The current process results in regular "oops" situations leading to no 
feedback. There are the "oops, must have missed that patch", and "oops, I 
thought I did reply to tell you what was wrong with that patch", both of 
which I have seen multiple times. These at least could be improved with a 
suitable system in place and result in some improvement even if the 
speculative post-rejection-review process is kept.

I'm not sure why you seem to be opposed to even attempting to find a better 
process that will work for everybody. The attempt to do so may well fail, but 
the surest way to fail is not to try.

-- 
troy at troy.rollo.name - Sydney, Australia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060928/4ff57442/attachment-0001.pgp