since you asked for reactions: * every bug fixed should result in a doctest: Example Zombie det() problem with LinBox, considered fixed twice, but reopened in both cases.
^^^ this should be first (even though this is an unordered list) * tickets are kind of like homicides: They either get solved in 48 hours, otherwise they have a tendency to become cold cases. ^^^ you may want to preface this with something like "sensitive people should cover their ears" On Sep 23, 11:00 am, mabshoff <[EMAIL PROTECTED] dortmund.de> wrote: > 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 athttp://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/ -~----------~----~----~----~------~----~------~--~---
