Changes between Version 5 and Version 6 of WorkflowPolicy

Timestamp:

10/15/10 23:45:04 (14 years ago)

Author:

jdreed

Comment:

--

WorkflowPolicy

@@ -1 @@
-{{{
-#!html
-<p style="font-weight: bold; font-size: 20pt; border: 1px solid black; text-align: center; background-color: #cc0000">DRAFT</p>
-}}}
-
 = Workflow Policy =
 
 This policy governs how source code changes eventually end up as packages in the production repository.
+
+Adopted by release-team, 15 October 2010.
 
 == Committing Code ==
@@ -15 +12 @@
 Anyone with repository access may commit code changes.  When appropriate, new Changelog entries should be created.  If you do not intend to immediately upload the package, the Distribution should be listed as "UNRELEASED".  
 
-Each commit generates mail to source-commits@mit.edu.  Any discussion about the commit should be summarized in e-mail by replying to the original commit message, even if the discussion happens over Zephyr.
+Each commit generates mail to source-commits@mit.edu.  Discussion of the commit can happen over e-mail or zephyr.  If discussion happens over zephyr and any agreed-upon modifications are not immediately committed, a summary of the discussion should be sent by replying to the source-commits e-mail.
 
-Commits should be reviewed within 2 business days.  Code should be ACK'd by at least $num members of debathena-root.  An ACK may occur by e-mail (replying to the original commit mail) or by zephyr to class debathena, instance r$rev.  If an ACK does not ocur
+Commits should be reviewed within 2 business days.  Code should be ACK'd by at least 1 member of debathena-root who is not the committer.  The ACK should occur by e-mail (replying to the original commit mail).  If an ACK does not occur at the end of 2 business days, the change is deemed to be approved and may be uploaded to Alpha.
 
 == Uploading to Alpha (development) ==
@@ -24 +21 @@
  * TTL: n/a
 
-Once code has been approved or the TTL has exceeded, it may be built and uploaded to the alpha (`development`) repository.  At this point, it should be tested by as many developers as possible.  Code requires 2 explicit ACKs to proceed to the next stage.  An ACK may occur in a Trac comment; a reply to a Trac e-mail, or a zephyr to debathena,apt,* with a body indicating the ACK and the package name and version.
+Once code has been approved or the TTL has exceeded, it may be built and uploaded to the alpha (`development`) repository.  At this point, it should be tested by as many developers as possible.  Code requires 2 explicit ACKs (one of which can be the original author) to proceed to the next stage.  An ACK may occur in a Trac comment; a reply to a Trac e-mail, or a zephyr to debathena,apt,* with a body indicating the ACK and the package name and version.
+
+Active developers should have easy access to a machine in the Alpha cluster.  IS&T-public Alpha machines are located in N42 (`cheshire-cat.mit.edu`) and the test cluster (`<FIXME>.mit.edu`).
 
 == Uploading to Beta (proposed) ==
@@ -35 +34 @@
 == Upload to Production ==
 
- * Prereq: (Explicit approval OR beta TTL expiration) AND ( today != Friday ) AND ( today != day_before_institute_holiday )
+ * Prereq: (Explicit approval OR beta TTL expiration) AND  (today = business_day ) AND ( today != (day_before_institute_holiday OR Friday))
 
-Once the beta TTL has expired or approval has been obtained, the package may be moved to the production repository.  This should not happen on Fridays or days before Insitute holidays without discussion by release-team.
+Once the beta TTL has expired or approval has been obtained, the package may be moved to the production repository.  This should happen on business days that are not Fridays or days before Insitute holidays.  With prior e-mail discussion, release-team can override the calendar requirements.