149
149
Anyone can "vote" on the mailing list. Core developers can also vote using
150
150
Bundle Buggy. Here are the voting codes and their explanations.
152
-1 really don't want it in current form
153
-0 somewhat uncomfortable
154
+0 comfortable but resubmission after changes requested
155
+1 conditional good to go after some minor changes
158
+1 conditional is used as a way to avoid another submit/review cycle for
159
patches that need small changes.
161
If a change gets two +1 votes from core reviewers, and no
162
vetos, then it's OK to come in. Any of the core developers can bring it
163
into the bzr.dev trunk and backport it to maintenance branches if required.
164
The Release Manager will merge the change into the branch for a pending
152
:approve: Reviewer wants this submission merged.
153
:tweak: Reviewer wants this submission merged with small changes. (No
155
:abstain: Reviewer does not intend to vote on this patch.
156
:resubmit: Please make changes and resubmit for review.
157
:reject: Reviewer doesn't want this kind of change merged.
158
:comment: Not really a vote. Reviewer just wants to comment, for now.
160
If a change gets two approvals from core reviewers, and no rejections,
161
then it's OK to come in. Any of the core developers can bring it into the
162
bzr.dev trunk and backport it to maintenance branches if required. The
163
Release Manager will merge the change into the branch for a pending
165
164
release, if any. As a guideline, core developers usually merge their own
166
165
changes and volunteer to merge other contributions if they were the second
167
166
reviewer to agree to a change.
added
removed
doc/developers/HACKING
