On Fri, Mar 2, 2012 at 1:06 AM, Keshav Kini <keshav.k...@gmail.com> wrote: > Robert Bradshaw <rober...@math.washington.edu> writes: >> On Wed, Feb 29, 2012 at 4:51 PM, Keshav Kini <keshav.k...@gmail.com> wrote: >>> William Stein <wst...@gmail.com> writes: >>>> It's difficult for me because they are patch in hg format, but I can't >>>> export a patch out of git in hg format. It's possible to import the >>>> code in from the trac ticket, but then if I make changes I have to >>>> export them as a git diff, then import them into another hg repo, then >>>> export them again. As far as I can tell -- no easy way to referee a >>>> trac ticket right now using git. I bet it would be possible for a >>>> git wizard to setup some scripts to make this easy. I think doing >>>> so is an important first step toward moving Sage developers to git. >>> >>> I see that as a waste of time. We should create scripts to facilitate a >>> new workflow, not the old one. The average Sage developer should not be >>> encouraged to use git just yet, I think. That is because, as you have >>> noticed, it is downright painful to use git to work on Sage right now. >>> Basically the only advantage right now is the ease of collaboration, >>> which Jason mentioned above. >>> >>> But the solution is not to create scripts that automate this painful >>> process. What we need to do is set up an infrastructure to support a >>> git-based workflow, not create scripts that dumb git down to support our >>> current workflow. (This will be covered in the Workflow SEP.) >> >> +1 (I do think we should have scripts and/or a sage command so the >> average developer doesn't even have to know that git (or whatever else >> we are settling on) is being used under the hood to submit new code >> and review/extend submitted code. They should be clearly defined in >> terms of git commands, so the semi-advanced user can use git directly >> with little/no hassle.) > > Right, `your post`_ about that a little while ago is definitely > informing my thoughts on all of this. > > .. _your post: > https://groups.google.com/d/msg/sage-notebook/P6M-_ajbXJQ/m4oG29xbi5QJ > >> As for issue tracking, I've heard a lot of complaints about the github >> one (especially before they launched their new system) and my only >> comment here is while it's nice to have issue tracking and source code >> repositories synchronized, there's no need to do so as long as we can >> link between the two (e.g. use standard naming conventions) Certainly >> using trac as a transient source code repository is rather ugly. > > I don't propose to get rid of our Trac instance, though I could be > persuaded otherwise - I don't really have a feel for what the various > popular issue tracker software packages are and what features they have. > > I personally have a passing acquaintance with bugzilla (e.g. Mozilla), > debbugs (e.g. Debian), JIRA (e.g. MusicBrainz), redmine (e.g. Quassel > IRC), trac (e.g. Sage), Roundup (e.g. python), google code (e.g. > cyanogenmod), github (e.g. sagenb), and bitbucket (e.g. evil-mode) issue > trackers. Of these, it seems to me that redmine, trac, google code, and > github are pretty lightweight; bugzilla, debbugs, and Roundup are also > pretty lightweight but also have the advantage / disadvantage that they > are strongly email-based (especially in the case of debbugs, where the > UI even sort of suffers for that fact); and JIRA is more heavyweight and > featureful, though it is also a paid, hosted service and not open > source. But I haven't put much thought into which of these categories is > best for Sage. Maybe someone else has? > > 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). > 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'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 :). - Robert -- 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
