Robert Bradshaw <rober...@math.washington.edu> writes: > On Fri, Mar 2, 2012 at 1:06 AM, Keshav Kini <keshav.k...@gmail.com> wrote: >> I do notice that David Roe's description for Review Days includes >> something like a feature request for better code review procedures, such >> as line comments. Github's tracker can do that without any further >> configuration, if we move to github, which is nice. > > Yep. Note that code reviewing and issue tracking are separable tasks, > and URLs are, well, universal (as well as easy to copy/paste and even > generate).
Very good point. However, we seem to be using Trac mostly for code review and less for issue tracking - as you might expect due to our policy of all code changes needing to come from a trac ticket. We mark tickets as "positive review", "needs review", "needs work", and "new", and care a lot about which of these states (of code review) the ticket is in. On the other hand, We also have "issue tracking"-related fields such as component, owner, priority, milestone, etc., but we don't really seem to care at all about these. component is mainly used to set owner, and owner is ignored. priority is vaguely important in that we don't put out a stable release of Sage unless there are no open "blocker" tickets. Milestone is basically useless as it's almost always set to the next planned stable release. Moving our code review to github would mean that we wouldn't really be using trac for much anyway, in which case why not just move our issue tracker there as well? (Possible answer: github's issue tracker is not extensible enough; see below.) Maybe my perception of our use of Trac is incorrect, though. >> Trac might be able >> to, if we do some hacking on it to make it understand where our >> repositories and people's forks are - I haven't looked into this. >> >> Assuming we do stay with Trac, I'm still undecided about whether we >> should post github-user/branch names on tickets in a special field, or >> whether we should automatically associate ticket #n with branches called >> github-user/trac-n. I'm leaning towards the former, to allow people to >> write code without first worrying about the trac ticket number, and also >> reduce the burden on boxen of finding these branches periodically. > > We do both :). If the field is empty, try to discover a "default" > location. I guess so. I'm wary of doing too much "trying to discover", though. IMO automated tools should follow some easily predictable routine which is well-documented. In this case it's certainly simple enough to explain what Trac would be doing. But for example take the patchbot - it actually tries to do some kind of (very basic) natural language processing to figure out what to do! I hope we can avoid doing anything on that level of "trying to discover" (and I wish the patchbot had a way to override that stuff too, perhaps a custom field on trac where you could input instructions in a standardized format). For example, if two people have branches named trac-n, the script should just do nothing, not try to pick the most recently updated one, or look for branch names in the comments, or whatever :) > I'm not worried about the load--it'll probably be light and > if need be we can parallelize the work (my desktop is "keeping up" > with all posted patches on trac with only 3 cores). More importantly, > developer-cpu-seconds are much more valuable than machine-cpu-seconds, > and I'll spend many of the latter to save any of the former :). Sure, I agree with that. -Keshav ---- Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
