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/ReleasePolicy
The comment on the change is:
made some parts more readable, removed some pontificating
------------------------------------------------------------------------------
== Who can make a release? ==
- Any member of the Apache SpamAssassin project (committers) can make a
- release designated with Apache.
+ Any committer on the Apache SpamAssassin project can make a release designated
+ with Apache.
== Who is in charge of a release? ==
@@ -24, +24 @@
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.
- 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
+ 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.
+ Pre-releases may be still be issued with one or more showstopper bugs, however.
- In addition, pre-releases may be more acceptable to the community with
- one or more showstopper bugs.
== What power does the RM yield? ==
@@ -60, +49 @@
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) has been followed, they should "roll" the release out. Of those 3 votes, 1 generally comes from the RM, and 2 from other committers.
- required procedure (including three +1 votes) has been followed, they
- should "roll" the release out.
== What can I call this release? ==
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/ReleasePolicy
The comment on the change is:
made some parts more readable, removed some pontificating
------------------------------------------------------------------------------
== Who can make a release? ==
- Any member of the Apache SpamAssassin project (committers) can make a
- release designated with Apache.
+ Any committer on the Apache SpamAssassin project can make a release designated
+ with Apache.
== Who is in charge of a release? ==
@@ -24, +24 @@
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.
- 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
+ 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.
+ Pre-releases may be still be issued with one or more showstopper bugs, however.
- In addition, pre-releases may be more acceptable to the community with
- one or more showstopper bugs.
== What power does the RM yield? ==
@@ -60, +49 @@
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) has been followed, they should "roll" the release out. Of those 3 votes, 1 generally comes from the RM, and 2 from other committers.
- required procedure (including three +1 votes) has been followed, they
- should "roll" the release out.
== What can I call this release? ==