Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Spamassassin Wiki" for change notification.
The following page has been changed by JustinMason:
http://wiki.apache.org/spamassassin/VotingProcedure
The comment on the change is:
note that committer votes are binding for patches
------------------------------------------------------------------------------
== SpamAssassin Apache Voting Procedure ==
- We follow the [http://www.apache.org/foundation/voting.html Apache Voting Procedure] with the below modifications.
+ We follow the [http://www.apache.org/foundation/voting.html Apache Voting Procedure], with the below modifications.
+
+ == Binding and Non-binding Votes ==
+
+ In all cases, votes are welcome as an indication of how people feel about the issues being discussed; however, only votes from certain groups are considered "binding".
+
+ For code modifications, patches, and R-T-C changes to svn, committers have the
+ binding votes. However, for "ready to release" and project-procedural votes,
+ votes must come from PMC members to be considered binding.
=== Time Delays for Code Modifications ===
@@ -17, +25 @@
explanation, then the code gets pulled.)
And please don't vote +1 unless you actually did something to check the
- patch. That means some form of testing or code review. You do not necessarily need to apply the patch to your local copy of SA, but do take a good hard look at it before voting +1.
+ patch. That means some form of testing or code review. You do not necessarily need to apply the patch to your local copy of SA, but do take a look at it before voting +1.
=== When in Review-then-Commit mode ===
@@ -45, +53 @@
=== Reverting code ===
- To veto code, you must issue an explicit -1 veto in a bug or in a reply to the check-in on the spamassassin-dev mailing list. If the
- veto is for a security-related fix, you may veto on a private forum. In addition, the veto must be accompanied with a technical reason. Vetos should be avoided for purely procedural reasons. If you are vetoing code, it is considered polite to allow the author an opportunity to respond or revert the code themselves, but it is not quite as imperative to wait if the change is very broken and fixing it would require significantly more effort than reverting it.
+ To veto code, you must issue an explicit -1 veto in a bug or in a reply to the
+ check-in on the spamassassin-dev mailing list. If the veto is for a
+ security-related fix, you may veto on a private forum. In addition, the veto
+ must be accompanied with a technical reason. Vetos should be avoided for
+ purely procedural reasons. If you are vetoing code, it is considered polite to
+ allow the author an opportunity to respond or revert the code themselves, but
+ it is not quite as imperative to wait if the change is very broken and fixing
+ it would require significantly more effort than reverting it.
=== Setting up Subprojects ===
Requires +1s from ''more than'' half of the PMC membership.
+
You have subscribed to a wiki page or wiki category on "Spamassassin Wiki" for change notification.
The following page has been changed by JustinMason:
http://wiki.apache.org/spamassassin/VotingProcedure
The comment on the change is:
note that committer votes are binding for patches
------------------------------------------------------------------------------
== SpamAssassin Apache Voting Procedure ==
- We follow the [http://www.apache.org/foundation/voting.html Apache Voting Procedure] with the below modifications.
+ We follow the [http://www.apache.org/foundation/voting.html Apache Voting Procedure], with the below modifications.
+
+ == Binding and Non-binding Votes ==
+
+ In all cases, votes are welcome as an indication of how people feel about the issues being discussed; however, only votes from certain groups are considered "binding".
+
+ For code modifications, patches, and R-T-C changes to svn, committers have the
+ binding votes. However, for "ready to release" and project-procedural votes,
+ votes must come from PMC members to be considered binding.
=== Time Delays for Code Modifications ===
@@ -17, +25 @@
explanation, then the code gets pulled.)
And please don't vote +1 unless you actually did something to check the
- patch. That means some form of testing or code review. You do not necessarily need to apply the patch to your local copy of SA, but do take a good hard look at it before voting +1.
+ patch. That means some form of testing or code review. You do not necessarily need to apply the patch to your local copy of SA, but do take a look at it before voting +1.
=== When in Review-then-Commit mode ===
@@ -45, +53 @@
=== Reverting code ===
- To veto code, you must issue an explicit -1 veto in a bug or in a reply to the check-in on the spamassassin-dev mailing list. If the
- veto is for a security-related fix, you may veto on a private forum. In addition, the veto must be accompanied with a technical reason. Vetos should be avoided for purely procedural reasons. If you are vetoing code, it is considered polite to allow the author an opportunity to respond or revert the code themselves, but it is not quite as imperative to wait if the change is very broken and fixing it would require significantly more effort than reverting it.
+ To veto code, you must issue an explicit -1 veto in a bug or in a reply to the
+ check-in on the spamassassin-dev mailing list. If the veto is for a
+ security-related fix, you may veto on a private forum. In addition, the veto
+ must be accompanied with a technical reason. Vetos should be avoided for
+ purely procedural reasons. If you are vetoing code, it is considered polite to
+ allow the author an opportunity to respond or revert the code themselves, but
+ it is not quite as imperative to wait if the change is very broken and fixing
+ it would require significantly more effort than reverting it.
=== Setting up Subprojects ===
Requires +1s from ''more than'' half of the PMC membership.
+