On Fri, Mar 2, 2012 at 1:45 AM, Keshav Kini <keshav.k...@gmail.com> wrote: > 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).
It would be much less useful if it simply refused to do anything in the face of ambiguity, and it does have an override. It's a balance between the cost of guessing wrong (very low), the value of guessing correctly (high) and the cost of manual specification (medium). For something like a compiler the costs are very different :). > 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 :) Or one could preemptively test both, assuming the cycles are available. For someone at the command line trying to review/pull a ticket, it should ask. >> 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 -- 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
