|
Size: 262
Comment: initial version
|
Size: 2862
Comment: Remove section duplicated from https://doc.sagemath.org/html/en/developer/trac.html#working-on-tickets
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from TracGuidelines | |
| Line 3: | Line 4: |
| == Trac Tickets == | <<TableOfContents>> |
| Line 5: | Line 7: |
| === Rules === | == Reviewing Tickets == |
| Line 7: | Line 9: |
| * '''One Issue Per Ticket''' * '''No Patchbombs''' * '''Sage Specific''' === Recommendations === |
* '''100% Doctests''': All new code must be 100% doctested. There is no way around this. * '''Bug Fixes Must Be Doctested''': The ticket that fixes an issue must also contain a doctest specifically to test the problem. This is not always possible, so this is not enforced in certain situations. * '''Test the reference manual:''' {{{sage -docbuild reference html}}} must produce no errors. * '''Test the Sage library:''' {{{make test}}} or {{{make ptest}}} (edit number of threads in makefile before using ptest!). |
| Line 13: | Line 14: |
| * '''Patches Preferred''': | |
| Line 15: | Line 15: |
| == Reviewing Patches == | |
| Line 17: | Line 16: |
| * '''Doctesting''': | == Milestones vs. Releases == * Milestones are usually goals to be met while working toward a release. In Sage's trac, we use milestones instead of releases, but unless somebody volunteers to clean up all the old milestones, we will stick with the current model. It doesn't make a whole lot of difference if we use milestone instead of release. * Finely grained releases are good. Release early and often is the way to go, especially as more and more patches are coming in. * It is a good idea to make a big release and schedule at least one more bugfix release after that to sort out the inevitable "doctest X is broken on distribution Y and compiler Z" problem. Given the number of compilers and operating systems out there, one has to be realistic to expect problems. A compile farm would certainly help to catch issues early. == Assigning Tickets == * Each ticket must have a milestone assigned. * If a ticket has a patch or spkg that is ready to be reviewed, assign it against the current milestone. * defect vs. enhancement vs. task: this can be tricky, but a defect should be something that leads to an exception or a mathematically wrong result. * If you are unsure to whom to assign the ticket, assign it to ''somebody''. * Certain categories have default people that get assign all issues. One example is mabshoff for ''memory leaks''. * If you have been assigned a ticket, you should either accept it or assign it back to ''somebody'' or ''tba''. Many people do not accept pending tickets at the moment. You have accepted a ticket if your name has a star next to it. === Comments === * It would be nice to add something about our conventions about titles; "[with patch, needs review]", and so on. Also, what exactly must be done to review a patch? I'd like to see more about this. --DanDrake * Based on recent mailing list discussion, there appears to be a standard for naming patches: trac_NNNN_name. If this is going to be preferred/required, it should be stated here. --PeterJeremy * What are the conventions regarding including people listed as spkg maintainers and/or upstream contacts in tickets? This needs to be documented here. --PeterJeremy |
Trac Guidelines for Sage
Contents
Reviewing Tickets
100% Doctests: All new code must be 100% doctested. There is no way around this.
Bug Fixes Must Be Doctested: The ticket that fixes an issue must also contain a doctest specifically to test the problem. This is not always possible, so this is not enforced in certain situations.
Test the reference manual: sage -docbuild reference html must produce no errors.
Test the Sage library: make test or make ptest (edit number of threads in makefile before using ptest!).
Milestones vs. Releases
- Milestones are usually goals to be met while working toward a release. In Sage's trac, we use milestones instead of releases, but unless somebody volunteers to clean up all the old milestones, we will stick with the current model. It doesn't make a whole lot of difference if we use milestone instead of release.
- Finely grained releases are good. Release early and often is the way to go, especially as more and more patches are coming in.
- It is a good idea to make a big release and schedule at least one more bugfix release after that to sort out the inevitable "doctest X is broken on distribution Y and compiler Z" problem. Given the number of compilers and operating systems out there, one has to be realistic to expect problems. A compile farm would certainly help to catch issues early.
Assigning Tickets
- Each ticket must have a milestone assigned.
- If a ticket has a patch or spkg that is ready to be reviewed, assign it against the current milestone.
- defect vs. enhancement vs. task: this can be tricky, but a defect should be something that leads to an exception or a mathematically wrong result.
If you are unsure to whom to assign the ticket, assign it to somebody.
Certain categories have default people that get assign all issues. One example is mabshoff for memory leaks.
If you have been assigned a ticket, you should either accept it or assign it back to somebody or tba. Many people do not accept pending tickets at the moment. You have accepted a ticket if your name has a star next to it.
Comments
It would be nice to add something about our conventions about titles; "[with patch, needs review]", and so on. Also, what exactly must be done to review a patch? I'd like to see more about this. --DanDrake
Based on recent mailing list discussion, there appears to be a standard for naming patches: trac_NNNN_name. If this is going to be preferred/required, it should be stated here. --PeterJeremy
What are the conventions regarding including people listed as spkg maintainers and/or upstream contacts in tickets? This needs to be documented here. --PeterJeremy