[RFC] tweak to voting rules

Martin Pool mbp at canonical.com
Fri Dec 1 01:49:34 GMT 2006


On 30/11/2006, at 1:33pm, Aaron Bentley wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I think we need to differentiate between two reasons for voting  
> against
> a patch:
> 1. This implementation needs work before we can accept it.
> 2. This patch is a bad idea, and we should never accept it, even if
> well-implemented.
>
> So I propose we change things slightly:
> - -1 : patch needs work
> - -2 : patch is a bad idea
>
> That will allow BB to categorize the -1 patches differently from  
> the -2
> patches, and still get the patches off the pending list, where they
> really don't belong.
>
> I suppose while we were at it, we could also change the positive  
> end of
> the scale:
>
> +1 : submittable, if you make certain changes
> +2 : submittable
>
> Any thoughts?

Distinguishing them in a way bundle buggy can understand makes sense  
and those categories are ok with me.  I'm ok to use those numbers,  
but it might be more discoverable (though less concise) to use  
keywords e.g. launchpad uses

     * needs-review

       The initial status. Also indicates a branch which is pending  
further review feedback from a reviewer.

       needs-reply
             The branch has been reviewed and awaits a response from  
the code/patch author.  (ie it needs to be changed and resubmitted)

       merge-conditional
             The branch has been approved for merging pending  
comments or minor fixes that the review pointed out in his review  
message.

       merge-approved
             The branch has been OK to be merged, unconditionally.

and we could also add a 'rejected' for when it's just not coming in.

-- 
Martin






More information about the bazaar mailing list