[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