On Wed, Sep 23, 2009 at 08:07:18PM -0700, Robert Bradshaw wrote:
> 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.
A big +1! The overhead of the current workflow is killing us (well, at
least seriously slowing us down).
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
