You know my objections.

On a theoretical level, patches should be reviewed in a timely manner.

In practice, they aren't. Worse, people will sometimes look at  
patches, not commit, but also provide no feedback. This leaves me  
wondering whether:
a) Nobody has looked at the patch
b) The patch is poor
c) The idea is poor

I have no objection to using patches if people will actually:
a) Review them in a timely manner. 1 week seems reasonable, 3 hours  
seems reasonable for a bug hunt
b) Feedback is always provided, even if a patch is rejected

There is nothing more demoralizing than working on a patch, sharing  
it, and getting absolutely no feedback. Ideally, it would be  
committed. But at least knowing why it's not would be helpful.

I don't know what the solution to this is. I personally think having a  
public branch works. If you don't, I can respect that.

But I have yet to see a viable alternative. Simply expecting someone  
to review a patch hasn't been working, so alternatives must be  
investigated, especially for bughunts.

On Feb 19, 2009, at 1:21 PM, Owen Winkler wrote:

> I think that we should not be using a single public-write branch for  
> bug
> hunts.  My concern with this is that changes are often poorly vetted
> before merging with trunk.  For the same reason that changes in code
> convention formatting of a whole file obscure a subtle logic change
> within that file, it is even more difficult to review changes when
> multiple logical or functional changes overlap.
>
> I don't know the solution.  I think I would rather patch and commit.
> Opponents of that idea typically argue that patches are never reviewed
> or committed, although I think that a bug hunt should imply the
> assurance that there will be committers specifically available for  
> this
> purpose.  Of course, the same ideas apply to this as to branches --  
> not
> every patch is going to get in, and you'd do better by not coding in a
> vacuum.


--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at http://groups.google.com/group/habari-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to