Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: converted to 1.6 markup

SpamAssassin Apache Voting Procedure

Wiki MarkupWe follow the \[http://incubator.apache.org/learn/voting.html Apache Voting Procedure\] , with the below modifications.

Time Delays

Votes should generally be permitted to run for at least 72 hours to provide an opportunity for all concerned persons to participate regardless of their geographic locations.

(Since it does say "generally", it seems reasonable exceptions to the 72 hour rule are allowed if you specify such in your vote, but let's always allow at least 24 hours or at least 48 hours if the weekend is involved. Remember, though, that if someone later vetos with a technical 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.

When in Review-then-Commit mode

Changes need consensus approval before being committed. "Consensus approval" refers to a vote which has completed with at least three binding +1 votes and no -1 vetos.

Yes, the author of a patch is allowed to vote as long as they're a committer; in general, if a committer uploads the patch, it's assumed they give it an implicit +1 unless specified otherwise.

Also, any changes need to go through a bug with the appropriate milestone.

When Review-then-Commit is optional

  • documentation
  • finishing off pre-existing T_ tests
  • non-controversial non-semantic style changes (fixing indentation, adding comments, but not actual code)
  • very simple, non-controversial, and absolutely safe bug fixes

Running 'make test'

'make test' should be run before committing anything, unless the change doesn't modify the code in any way (such as a documentation change). If you check in something that breaks 'make test', you have Done A Bad Thing.

If you send out a patch for C-T-R, and your patch manages to break 'make test' on its own (ie. not through interaction with other current review patches), that is Also Bad.

Reverting code

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 ASF votes, votes must come from PMC members to be considered binding.

(Note: previously committers could vote for releases, but this has had to be changed, due to ASF regulations. While the Apache Voting page is a little unclear on the subject, discussion on the 'legal-discuss' list has made it clear that it is part of the ASF's bylaws that PMCs, and only PMCs, can direct this action. See this message for example.)

Votes For Code Modifications

See DevelopmentMode for notes on C-T-R and R-T-C voting, and vetoing code changes.

Setting up Subprojects

Requires +1s from more than half of the PMC membership.to be added