On Mon, 2007-02-12 at 10:06 -0500, Greg Dekoenigsberg wrote:
> On Sun, 11 Feb 2007, Mike C. Fletcher wrote:
> 
> > Um, speaking as a Gentoo user, that's last bullet is a strange statement. 
> > The problem seems to be that you guys seem to be building from *head* on 
> > some 
> > huge number of projects (I say seem to be because I just wound up having to 
> > give up trying to get sugar installed due to broken builds).  That would 
> > require very high discipline on all of the projects to make it work.
> >
> > 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 
> > component.
> >
> > Someone who just wants to use the environment (i.e. almost *all* new 
> > developers) could then build the stable tags, someone who wants to work 
> > with 
> > the latest and greatest could use the testing tags and contribute to the 
> > testing of them by their building.  When everyone is building head in all 
> > these projects, by contrast, you are basically having every new developer 
> > build a different piece of software, with no idea whether what they are 
> > building is actually usable.  Given that new developers are *new*, and thus 
> > unlikely to know whether they are seeing a failure in their usage or the 
> > code 
> > itself, knowing that what they are trying to do is *possible* is a great 
> > help 
> > for them.
> >
> > Sure, someone might get code that's 2 or 3 weeks out of date, but if they 
> > are 
> > working on a particular module, they'd set their tag to "HEAD" for that 
> > piece 
> > and be on the bleeding edge for that piece.
> 
> +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 
> difficult.
> 

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.

Marco

_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar

Reply via email to