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 DanielQuinlan:
http://wiki.apache.org/spamassassin/ReleasePolicy
The comment on the change is:
new release policy draft
New page:
== Who can make a release? ==
Any member of the Apache SpamAssassin project (committers) can make a
release designated with Apache.
== Who is in charge of a release? ==
The release is coordinated by the Release Manager (RM). Since this job
requires coordination of the development community (and access to SVN),
only committers to the project can be RM. However, there is no set RM.
Any committer may perform a release at any time. In order to facilitate
communication, it is deemed polite to alert the community with your
planned release schedule before executing the release. A release should
only be made when there is a plan to publicly release it. (A release
should not be made only for private distribution. A private release is
more suitable for that.)
== Who may make a good candidate for an RM? ==
Someone with lots of time to kill. Being an RM is a very important job
in our community because it takes a fair amount of time to produce a
stable release. In general, our experience has shown that a
well-coordinated release fares better than non-coordinated releases.
== When do I know if it is a good time to release? ==
It is our convention to indicate blocking issues in Bugzilla with the
severity set to critical. A showstopper entry does not automatically
imply that a release cannot be made. As the RM has final authority on
what makes it into a release, they can choose to ignore the entries.
An item being denoted as critical indicates that the group has come to a
consensus that no further releases can be made until the entry is
resolved.
In addition, pre-releases may be more acceptable to the community with
one or more showstopper bugs.
== What power does the RM yield? ==
Regarding when a release is made, the RM is the unquestioned authority.
No one can contest what makes it into the release so long as the release
procedure defined in build/README has been followed. The community will
judge the release's quality after it has been issued, but the community
can not force the RM to hold off a release for a feature. Remember that
this document is only a guideline to the community and future RMs - each
RM may run a release in a slightly different way. If you don't like
what an RM is doing, start preparing for your own competing release.
== How can an RM be confident in a release? ==
The RM must follow the release procedure defined in build/README. This
is project policy set by the PMC and is not optional. Once the tree has
been suitably tested by the RM and any other interested parties and the
required procedure (including three +1 votes), they should "roll" the
release out.
== What can I call this release? ==
There are three names for releases approved by the PMC:
* pre-releases (alpha)
* release candidates (beta)
* full release (general availability)
The type of release needs to be chosen before beginning the release
procedure since it is part of the tagging of the tree, etc.
Pre-release indicates that the release is not meant for mainstream usage
or may have serious problems that prohibits its use. Release candidates
are expected to work and perform basic tasks with no serious issues or
work remaining (like optimizing the scores). However, there may be
problems with this release that prohibit its widespread adoption. Full
releases are recommended for production usage.
== Who can vote? ==
Non-committers may cast a vote for a release's quality. In fact, this
is extremely encouraged as it provides much-needed feedback to the
community about the release's quality. However, only binding votes
casted by committers count towards the designation. Note that no one
may veto a release. The PMC or the release manager may revoke all votes
on a release if a new major problem is discovered prior to publication
of a release and request a revote. However, once there are greater than
3 positive votes, the release may be made at any time. In addition, the
RM may decide against making a release even if the required votes have
been made.
== Oops. We found a problem ==
If the "point of no return" described in the build/README has not been
reached, then the release may be abandoned and begun again.
If the "point of no return" has been reached, but the release has not
been made public via tarballs, then the release may be abandoned, but
the version number is considered burned.
If the release has been made public and the problem is so severe that
the release absolutely should not have been made, then the tarballs may
be renamed to "-dontuse" and a new announcement may be sent at the
discretion of the release manager.
You have subscribed to a wiki page or wiki category on "Spamassassin Wiki" for change notification.
The following page has been changed by DanielQuinlan:
http://wiki.apache.org/spamassassin/ReleasePolicy
The comment on the change is:
new release policy draft
New page:
== Who can make a release? ==
Any member of the Apache SpamAssassin project (committers) can make a
release designated with Apache.
== Who is in charge of a release? ==
The release is coordinated by the Release Manager (RM). Since this job
requires coordination of the development community (and access to SVN),
only committers to the project can be RM. However, there is no set RM.
Any committer may perform a release at any time. In order to facilitate
communication, it is deemed polite to alert the community with your
planned release schedule before executing the release. A release should
only be made when there is a plan to publicly release it. (A release
should not be made only for private distribution. A private release is
more suitable for that.)
== Who may make a good candidate for an RM? ==
Someone with lots of time to kill. Being an RM is a very important job
in our community because it takes a fair amount of time to produce a
stable release. In general, our experience has shown that a
well-coordinated release fares better than non-coordinated releases.
== When do I know if it is a good time to release? ==
It is our convention to indicate blocking issues in Bugzilla with the
severity set to critical. A showstopper entry does not automatically
imply that a release cannot be made. As the RM has final authority on
what makes it into a release, they can choose to ignore the entries.
An item being denoted as critical indicates that the group has come to a
consensus that no further releases can be made until the entry is
resolved.
In addition, pre-releases may be more acceptable to the community with
one or more showstopper bugs.
== What power does the RM yield? ==
Regarding when a release is made, the RM is the unquestioned authority.
No one can contest what makes it into the release so long as the release
procedure defined in build/README has been followed. The community will
judge the release's quality after it has been issued, but the community
can not force the RM to hold off a release for a feature. Remember that
this document is only a guideline to the community and future RMs - each
RM may run a release in a slightly different way. If you don't like
what an RM is doing, start preparing for your own competing release.
== How can an RM be confident in a release? ==
The RM must follow the release procedure defined in build/README. This
is project policy set by the PMC and is not optional. Once the tree has
been suitably tested by the RM and any other interested parties and the
required procedure (including three +1 votes), they should "roll" the
release out.
== What can I call this release? ==
There are three names for releases approved by the PMC:
* pre-releases (alpha)
* release candidates (beta)
* full release (general availability)
The type of release needs to be chosen before beginning the release
procedure since it is part of the tagging of the tree, etc.
Pre-release indicates that the release is not meant for mainstream usage
or may have serious problems that prohibits its use. Release candidates
are expected to work and perform basic tasks with no serious issues or
work remaining (like optimizing the scores). However, there may be
problems with this release that prohibit its widespread adoption. Full
releases are recommended for production usage.
== Who can vote? ==
Non-committers may cast a vote for a release's quality. In fact, this
is extremely encouraged as it provides much-needed feedback to the
community about the release's quality. However, only binding votes
casted by committers count towards the designation. Note that no one
may veto a release. The PMC or the release manager may revoke all votes
on a release if a new major problem is discovered prior to publication
of a release and request a revote. However, once there are greater than
3 positive votes, the release may be made at any time. In addition, the
RM may decide against making a release even if the required votes have
been made.
== Oops. We found a problem ==
If the "point of no return" described in the build/README has not been
reached, then the release may be abandoned and begun again.
If the "point of no return" has been reached, but the release has not
been made public via tarballs, then the release may be abandoned, but
the version number is considered burned.
If the release has been made public and the problem is so severe that
the release absolutely should not have been made, then the tarballs may
be renamed to "-dontuse" and a new announcement may be sent at the
discretion of the release manager.