Trac: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
Line 7: Line 7:
From Michael's notes on recent meeting: http://lists.laptop.org/pipermail/devel/2008-June/015749.html
From Michael's notes on recent meeting: http://lists.laptop.org/pipermail/devel/2008-June/015749.html


Please comment there or here. Once we are agreed on the conventions we should also link them from Trac per Bert's suggestion.
Please comment on that thread. Once we are agreed we can update this page and link them from Trac per Bert's suggestion.


In yesterday's software status meeting, we formulated some conventions
In yesterday's software status meeting, we formulated some conventions
for using Trac for the next few months. They are:
for using Trac for the next few months. They are:


1. The release team - presently including me, Greg Smith, and Kim Quirk
1. The release team - presently including me, 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.
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
2. Greg will record customer preference data according to whatever means he sees fit and will inform us of these data in regular meetings.
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
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 on the frontpage of Trac.
'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 on the frontpage of Trac.
4. People should indicate the release they _wish_ that changes would
4. People should indicate the release they _wish_ that changes would land in via the Milestone field.
land in via the Milestone field.


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


8.2.0:+ -- means that the change is "within reach" or, preferably,
8.2.0:+ -- means that the change is "within reach" or, preferably, has been included in a dist-olpc3-updates series build.
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 "in danger of missing the boat".


8.2.0:- -- the change is unlikely to be ready for release
8.2.0:- -- the change is unlikely to be ready for release


(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
6. When it's unambiguous, people should attach test results to tickets with tags like:
with tags like:


joyride-2027:- -- the issue persists in joyride-2027
joyride-2027:- -- the issue persists in joyride-2027
joyride-2029:+ -- the issue was not reproducible in joyride-2027
joyride-2029:+ -- the issue was not reproducible in joyride-2027


If appropriate, please also describe the test procedure that was
If appropriate, please also describe the test procedure that was executed to generate the result.
executed to generate the result.


7. We have added a 'Needs Action' field to Trac with several states for
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.
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. The 'priority' field is a place for component maintainers to say what
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.
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.)


Please comment freely.
Please comment freely.

Revision as of 10:48, 27 June 2008

Trac is an online system for tracking software bugs and organizing software development. OLPC uses trac to coordinate all its official software development. Bugs, features, and other work items are entered into trac as trac tickets. This assigns the work a unique reference number, which can be used to track progress using the trac system. (See also: submitting bugs)

Trac Usage Guidelines

Gregorio 10:45, 27 June 2008 (UTC)

From Michael's notes on recent meeting: http://lists.laptop.org/pipermail/devel/2008-June/015749.html

Please comment on that thread. Once we are agreed we can update this page and link them from Trac per Bert's suggestion.

In yesterday's software status meeting, we formulated some conventions for using Trac for the next few months. They are:

1. The release team - presently including me, 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 on the frontpage of Trac.

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

5. 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>:+.)

6. 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.

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. 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.)

Please comment freely.

Regards,

Michael

Trac ticket wiki markup

The OLPC wiki is configured to allow automatic linking to trac tickets using special markup. For example, this code:

* <trac>1</trac>

renders as the a link to the page for trac ticket item number 1:

  • <trac>1</trac>


See also: