That is *very* cool. We should put that in a wiki page so we can plan a way to transition to a system like that.
On Thu, Sep 24, 2009 at 11:07 AM, Robert Bradshaw < rober...@math.washington.edu> wrote: > > On Sep 22, 2009, at 8:51 AM, Jason Grout wrote: > > > Tim Joseph Dumol wrote: > >> Sorry, I mean't we *can't* use it without a bit of modification. > > > > > > A google search for "rietveld mercurial" shows lots of work on this > > problem. > > Very cool. > > As mentioned, I used this system all summer, and it is very nice > compared to how we're using trac. Trac is great at what it was meant > for--bugtracking, but it was not meant to be part of a manual > revision control system. I actually started thinking about this well > before this summer, but now that I've used a fairly nice setup it's > even more clear how good it is when the system gets out of the way > and lets you focus on the work. > > Here's my ideal system (which rietveld may or may not be a part of, > but certainly it'd be better to not start something from scratch). > > (0) I hack on my own code, committing as I want, the normal mercurial > way. > (1) I run a sage command that takes all my changes and uploads them > to trac (or rietveld, or Review Board, or ...). It may or may not > flatten them. The ticket description should be no more than the > commit description (i.e. our commit descriptions should be a lot more > verbose.) > (2) This patch automatically gets applied to the current alpha, any > merge problems, build problems (including documentation), or test > failures get reported and bounced back. Linting could happen at this > point too (everything from no tabs to coverage to "Sage:" in docstrings) > (3) Upon a successful build (or even not) this build gets saved and > can be accessed and played with (via the notebook or by ssh-ing into > a virtual machine). The code can be browsed and commented on. > (4) Reviewer makes comments, as a whole or line-by-line. They can use > (3), browse the code, and have a sage command like sage -merge that > will quickly update their local copy to the state of the ticket, and > allow them to push as well. > (5) I can quickly address those comments via a sage -b into that > branch (or otherwise using queues/etc. to get back to my ticket > state), make my changes, and re-push to trac. Building and tests > happen after every push. This point here is not to be underestimated-- > I think it will greatly improve the quality of the code to lower the > overhead of the feedback loop. > (6) When the reviewer is happy, he marks it as positive review. > (7) The release manager(s) approve the patch. At this point they know > it builds, passes tests, and has at least one positive review. It > goes into a queue. > (8) Patches in the queue get applied to the current alpha. This > implies a moving alpha, which one knows builds and passes all tests > on at least one system. It should be easy to upgrade to that alpha. > (9) People can (easily) donate computer time to build and test > alphas, which will greatly increase hardware coverage. Bisection can > be used to locate the offending ticket in case of failure. > > Note that one can still work "out of the system" mailing around > mercurial bundles and patches, so there's no lock-in. I'm sure there > are a lot of more details to work out (like how to handle spkgs, > which I think could still fit into the above system), but I think a > system like the above would make the job easier for both developers > and release managers. It might tax the computer systems a bit, but > that's not what we're short on now (or, probably, into the > foreseeable future). Every step above that involves a human needs a > human, and doesn't require tons of overhead. > > - Robert > > P.S. I won't be the one setting this up, at least I hope someone > beats me to it before I have time to tackle something like this next > year. > > > > > -- Tim Joseph Dumol <tim (at) timdumol (dot) com> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
