Changes between Version 5 and Version 6 of WorkflowPolicy


Ignore:
Timestamp:
10/15/10 23:45:04 (11 years ago)
Author:
jdreed
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WorkflowPolicy

    v5 v6  
    1 {{{ 
    2 #!html 
    3 <p style="font-weight: bold; font-size: 20pt; border: 1px solid black; text-align: center; background-color: #cc0000">DRAFT</p> 
    4 }}} 
    5  
    61= Workflow Policy = 
    72 
    83This policy governs how source code changes eventually end up as packages in the production repository. 
     4 
     5Adopted by release-team, 15 October 2010. 
    96 
    107== Committing Code == 
     
    1512Anyone 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".   
    1613 
    17 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. 
     14Each 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. 
    1815 
    19 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 
     16Commits 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. 
    2017 
    2118== Uploading to Alpha (development) == 
     
    2421 * TTL: n/a 
    2522 
    26 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. 
     23Once 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. 
     24 
     25Active 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`). 
    2726 
    2827== Uploading to Beta (proposed) == 
     
    3534== Upload to Production == 
    3635 
    37  * Prereq: (Explicit approval OR beta TTL expiration) AND ( today != Friday ) AND ( today != day_before_institute_holiday ) 
     36 * Prereq: (Explicit approval OR beta TTL expiration) AND  (today = business_day ) AND ( today != (day_before_institute_holiday OR Friday)) 
    3837 
    39 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. 
     38Once 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.