[sugar] A philosophical question
Mike C. Fletcher
Sun Feb 25 21:30:13 EST 2007
Marco Pesenti Gritti wrote:
> On Mon, 2007-02-12 at 10:06 -0500, Greg Dekoenigsberg wrote:
>> On Sun, 11 Feb 2007, Mike C. Fletcher wrote:
>>> If you had your build environment use a tag/revision in the source control
>>> system for each project and only update the version used when your core
>>> developers *know* that the new version has built and run on a couple of dozen
>>> boxes you'd have a far greater chance of getting new developers built without
>>> problems. In short, you'd have a testing tag and a stable tag for each
>> +1. Especially since this is precisely what Sugar users end up
>> replicating -- the hard way. I'm building Sugar in its entirety, every
>> day, and whenever I find a build that "works", I use it for a while.
>> Requires some additional overhead to determine what Sugar builds are
>> stable, of course -- and when you're moving rapidly in HEAD, that can be
We (an unknown number at the moment) are going to be sprinting on OLPC
at PyCon for the next 4 days (give or take). One of our top priorities
is trying to implement this scheme for sugar-jhbuild so that we can make
it possible for new developers to get started.
Any suggestions on where to look for how the system works or where we
would put our fingers to get it working. The key issues being "how do
we alter sugar-jhbuild to build a particular version of a sub-project?"
and "what versions should we start with to get a working version" (i.e.
can someone who has a working build look at the versions and do the
equivalent of "svn info" to let us know the versions to start with).
Have fun all,
> If someone wants to maintain a stable list of modules in sugar-jhbuild
> we can totally do that. We could either base it on modules releases
> (using tarballs or tags) or the list maintainer could pick stable
> snapshots from git.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Sugar-devel