Hello, I will do a 15 minute talk about trac and the Sage development process. I figured that because
a) not everybody will be there b) I might miss some issues and will probably be completely wrong on others c) we might not have a lot of time after to discuss the issues it would be a good idea to get some input from sage-devel. The following is not very structured and written down in "stream of consciousness" mode. So rip it apart and let me know how to do this better. Once we get closer I will obviously turn this into a proper presentation, but it should also end up somewhere in the documentation. *Better Sage Project Management With The Help of Trac* # Opening Remarks # The is more about than just the use of trac to help out with Sage development, but also about work flow in general and how we can make developing Sage more efficient now that more and more developers are joining Sage. # The Situation # * "everything you work on is a ticket" rule seems to work out well. * the number of open tickets keeps on rising (from about 220 to slightly under 300 at the moment), but turnover is rather high. * Bug Days have closed up to 70 ticker, the lower bounds seems to be about 40. * The old cruft, i.e. tickets closed a long the way, that was left in trac seems to have all been closed. * If you do development for Sage or consider yourself a user how wants to report issues get account for Sage's trac installation: either email William Stein or alternatively contact him on #sage-devel on freenode. Preferably get a tray account with the same name as your google group nickname, so that one know how to contact you. # 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 we will stick with the current model * finely grained releases are good, release early and often * it is realistic to make a big release and schedule at least one bugfix release after that to sort out the inevitable "doctest X is broken on distribution Y and compiler Z" problem # Opening Tickets # * Before opening a ticket make sure that nobody else has opened a ticket about the same or closely related issue. * It is better to open several specific tickets than one that is very broad. * Be precise: If foo doesn't work on OSX, but is fine on Linux mention that in the title, also use the keyword option to make searches pick up the issue * be careful with the priority: "blocker" should be used sparingly, don't be surprised that such a ticker is reclassified ## Working On Tickets ## * tickets are kind of like homicides: They either get solved in 48 hours, otherwise they have a tendency to become cold cases. This is mostly an issue with defects, there are many enhancements possible for Sage, but too few developers to implement all the good ideas. But it is useful to keep ideas in a central place because in the google groups they tend to get lost once they drop off the first page * If you are a developer be nice and try to solve a stale/old ticket every once in a while. * I and mhansen (and some other people I properly forgot to mention) regularly do triage, especially before Bug Days. Triage in this context means that we look at new bugs and classify them according to out perceived priority. * every bug fixed should result in a doctest: Example Zombie det() problem with LinBox, considered fixed twice, but reopened in both cases. # Assigning Tickets # * each ticket should have a milestone assigned * defect vs. enhancement vs. task * if you are unsure whom to assign to assign to somebody or was * certain categories have default people to assign to * if you have been assigned a ticket you should either accept it or assign it back to "somebody" or "tbd" # Closing Tickets # * if you have a solution/patch attach it to the ticket and indicate that there is a solution available by adding "[with patch]" to the title. It might also be a good idea to reassign the ticket to the current bugfix release if it is scheduled for some milestone that is far in the future. * Do not close the ticket, but let William close it once the patch has actually been merged. In the past patches have been lost due to the fact that somebody closed the ticket and William never saw the patch. Another possibility is especially during Bug Days or interactive discussions via IRC that you can close it after you have been encouraged to do so. * Somewhat on an exception is wontfix or duplicate tickets, but it is also a good idea to check with somebody in IRC. Alternatively write an email to sage-devel or William directly so he can react in case a mistake was made. # Desirable Trac Features # * more statistics * a default CC to a google group sage-trac, this requires that a google group is created [done] and that somebody with admin access to sagemath.org enables smtp for trac [not done yet] * loads more interesting bits at http://trac-hacks.org/ - but we should not merge in too many extensions because it makes maintainability more difficult once we upgrade to newer trac releases. I maintain several phpBB installations and not adding a wild bunch of mods proved to be a smart choice. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
