Patchwork (was Re: Governance revisited)
troy at troy.rollo.name
Wed Sep 27 15:42:25 CDT 2006
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
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
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
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060928/4ff57442/attachment-0001.pgp
More information about the wine-devel