Trac conventions: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
(add new sec. 5)
Line 1: Line 1:

1. The release team - presently including Michael Stone, Greg Smith, and Kim Quirk will occasionally tag a ticket as 'blocks:8.2.0' to indicate that it blocks the 8.2.0 release. Such tickets will be understood to be part of our release criteria. If you think that a ticket should be so marked, please poke us until we deal with it.
1. The release team - presently including Michael Stone, Greg Smith, and Kim Quirk will occasionally tag a ticket as 'blocks:8.2.0' to indicate that it blocks the 8.2.0 release. Such tickets will be understood to be part of our release criteria. If you think that a ticket should be so marked, please poke us until we deal with it.


Line 8: Line 7:
4. People should indicate the release they _wish_ that changes would land in via the Milestone field.
4. People should indicate the release they _wish_ that changes would land in via the Milestone field.


5. To nominate a "release blocker" for a release, use the following tags:
5. People should indicate their confidence that the changes _will_ land by tagging tickets with strings like:

blocks?:8.2.0 -- proposed release blocker

blocks:8.2.0 -- set by the release team to mark an accepted release blocker

blocks-:8.2.0 -- set by the release team to mark a rejected release blocker

6. People should indicate their confidence that the changes _will_ land by tagging tickets with strings like:


8.2.0:+ -- means that the change is "within reach" or, preferably, has been included in a dist-olpc3-updates series build.
8.2.0:+ -- means that the change is "within reach" or, preferably, has been included in a dist-olpc3-updates series build.
Line 18: Line 25:
(NB: Please be conservative in tagging things <rel>:+.)
(NB: Please be conservative in tagging things <rel>:+.)


6. When it's unambiguous, people should attach test results to tickets with tags like:
7. When it's unambiguous, people should attach test results to tickets with tags like:


joyride-2027:- -- the issue persists in joyride-2027
joyride-2027:- -- the issue persists in joyride-2027
Line 26: Line 33:
If appropriate, please also describe the test procedure that was executed to generate the result.
If appropriate, please also describe the test procedure that was executed to generate the result.


7. We have added a 'Needs Action' field to Trac with several states for common actions (and various kinds of ignorance of what action is needed.) Please use it. Let us know if we need to change the set of actions.
8. We have added a 'Needs Action' field to Trac with several states for common actions (and various kinds of ignorance of what action is needed.) Please use it. Let us know if we need to change the set of actions.


See [[Trac ticket workflow]] for the present ticket workflows.
See [[Trac ticket workflow]] for the present ticket workflows.


8. The 'priority' field is a place for component maintainers to say what they think is important; however, we expect that our regular IRC meetings and emails will be the primary vehicle for communicating day-to-day priority information.
9. The 'priority' field is a place for component maintainers to say what they think is important; however, we expect that our regular IRC meetings and emails will be the primary vehicle for communicating day-to-day priority information.


(NB: We may revisit the priority information decisions.)
(NB: We may revisit the priority information decisions.)

Revision as of 19:22, 6 August 2008

1. The release team - presently including Michael Stone, Greg Smith, and Kim Quirk will occasionally tag a ticket as 'blocks:8.2.0' to indicate that it blocks the 8.2.0 release. Such tickets will be understood to be part of our release criteria. If you think that a ticket should be so marked, please poke us until we deal with it.

2. Greg will record customer preference data according to whatever means he sees fit and will inform us of these data in regular meetings.

3. Kim wants a way to keep track of 'critical' bugs. Michael defined 'critical bugs' as those bugs which receive the most careful oversight by the release team. Shortly, the release team will invent a convention for identifying such bugs which permits their inclusion in reports. These reports will be listed above.

4. People should indicate the release they _wish_ that changes would land in via the Milestone field.

5. To nominate a "release blocker" for a release, use the following tags:

     blocks?:8.2.0 -- proposed release blocker
     blocks:8.2.0  -- set by the release team to mark an accepted release blocker
     blocks-:8.2.0 -- set by the release team to mark a rejected release blocker

6. People should indicate their confidence that the changes _will_ land by tagging tickets with strings like:

     8.2.0:+ -- means that the change is "within reach" or, preferably, has been included in a dist-olpc3-updates series build.
     8.2.0:? -- the change is "in danger of missing the boat".
     8.2.0:- -- the change is unlikely to be ready for release
  (NB: Please be conservative in tagging things <rel>:+.)

7. When it's unambiguous, people should attach test results to tickets with tags like:

     joyride-2027:-  --  the issue persists in joyride-2027
     joyride-2029:+  --  the issue was not reproducible in joyride-2027
  If appropriate, please also describe the test procedure that was executed to generate the result.

8. We have added a 'Needs Action' field to Trac with several states for common actions (and various kinds of ignorance of what action is needed.) Please use it. Let us know if we need to change the set of actions.

   See Trac ticket workflow for the present ticket workflows.

9. The 'priority' field is a place for component maintainers to say what they think is important; however, we expect that our regular IRC meetings and emails will be the primary vehicle for communicating day-to-day priority information.

  (NB: We may revisit the priority information decisions.)