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. 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. -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
