On Fri, May 6, 2011 at 12:12 AM, Keshav Kini <[email protected]> wrote: > Hi Jeroen, > > I'd suggest that SPKG authors make their final commit themselves rather than > just allowing Jeroen's script to do it for them - this keeps the "blame > history" intact (assuming Jeroen's script doesn't mine people's names from > SPKG.txt and commit under those names!).
I think it would use the user's .hgrc file. > I sometimes worry we're not really using Mercurial for anything. I agree. > http://hg.sagemath.org/ paints a very unrealistic picture of the development > of Sage, for example, in comparison to how a real open source project's code > repository should look - take for example matplotlib ( > http://github.org/matplotlib ), ipython ( http://github.com/ipython ), > Octave ( http://hg.savannah.gnu.org/hgweb/octave ), etc. Especially with the longer release cycles. At the very least it'd be nice to have a public "devel" repo updated at every alpha release. And I'd love to have a live head to test and rebase against. Something like the sage merger script, but automated as every ticket on trac with positive review + release manager approval + passing on these X systems (on top of last previous head). It would just crawl forward over time and always be (relatively) stable. > To be frank, when > even you, who are in ultimate charge of our source control, say you are not > very fluent with the source control mechanism we use, it must mean we are > all kind of stumbling around... Are we just using hg as a convenient way to > generate patches and nothing more? I'm in no way an expert on Mercurial or > on software development practices but these things do worry me. Over the years, we've moved to using trac as our revision control mechanism, and mercurial just to generate patches and keep track of (limited) history. On top of that we don't have good automated/cli interfaces for dealing with trac, so in some ways it's a step back from just emailing patches around (though in others a step forward). The pull-request model of google code/github I think is a much nicer one, but momentum is hard to change. There's also the advantage of iterating on the actual commits to produce a cleaner history (e.g. folding patches together, making corrections after discussion), though that could be incorporated into the fork/pull model as well (or keeping patch queues under revision control, a la sage-combinat). The other problem is that so much isn't under revision control (eg. what versions of spkgs to use), or in multiple repositories that need to be kept in sync. Were I to design the system from scratch, I'd put all our code (devel/scripts/...) in a single repo, along with the top-level files, and a list of dependencies (spkgs). Building sage would fetch (locally or remotely) the dependencies listed and build them in such a way that changing the list of dependencies and re-building would easily and cheaply reversible. I would probably still build my own Python, but may require it (flexible version) as a bootstrapping prerequisite. Whether the non-upstream parts of an spkg belong in the spkgs or the main repo, I'm not sure, but I'd rather *everything* be expressed as commit to a single repository (possibly moving a pointer to some new, vanilla upstream source, rather than putting all upstream sources in our repo). If others have similar views, maybe we could move in that direction. - Robert -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
