|
Size: 2862
Comment: Remove section duplicated from https://doc.sagemath.org/html/en/developer/trac.html#working-on-tickets
|
← Revision 48 as of 2022-04-18 03:58:24 ⇥
Size: 0
Comment: duplicates https://doc.sagemath.org/html/en/developer/trac.html
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from TracGuidelines = Trac Guidelines for Sage = <<TableOfContents>> == 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 |
