Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] "staging" grimoire instead of devel for development spells as opposed to WIP spells?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] "staging" grimoire instead of devel for development spells as opposed to WIP spells?
  • Date: Fri, 25 Feb 2005 15:15:57 -0800

On Fri, Feb 25, 2005 at 02:47:22PM -0800, Eric Sandall wrote:
> Quoting "Mathieu L." <lejatorn AT smgl.homelinux.net>:
> > From what I've experienced, the flaw in the way we update stuff is that
> > even users in stable are somehow "testing" the stable grimoire because
> > even if a spell is "clean" in test doesn't insure it will work fine in
> > stable.
> > Of course, I'm pointing this out and I have no immediate solution,
> > however an idea just occured to me: we could have a distinction between
> > devs
> > who use stable grimoire (or willingly users) and real "simple" users who
> > wants the least hassle. For each spell there would be a kind of
> > "pre-release" of the stable version for a pool of ppl to test it
> > (I would be one of those for example, as I'm using stable grimoire) and,
> > say a week later, it would be "officially" released. That could decrease
> > the number of annoying glitches users run into when updating.
> >
> > I'm mainly proposing that for the future, because atm I think we have a
> > pretty high devs/users ratio, but if smgl really grows to have a large
> > user base this ration will notably decrease and I guess a lot of users
> > would be happy to have an smgl which just updates smoothly.
> >
> > Whadya all think about that?
>
> We could have a machine (or better yet a cluster of machines) who's sole
> job is
> to do the following:
> 1) Update test and stable Perforce repositories on the machine
> 2) Pull in changes from test to stable that have been in test for at least
> two
> weeks
> 3) Resolve the differences (probably `p4 resolve -at`)
> 4) Run Prometheus[0] on what's in the not-yet-submitted stable
> 5) Once Prometheus is done, revert any spells that failed and then submit
> the
> rest
> 6) Rinse and repeat every week/two weeks/month/whatever interval we can get
> Prometheus to finish the stable grimoire in. ;)
>
> Would this be feasible or even wanted?
>

I think its feasable and was one of the ideas I had in mind as well.

If we took test moved it to a staging area, had a bunch of machines crank
on it for a while, then have a task force to fix problems that show up,
verify them with prometheus, then back port to devel/test.

Then repeat until all the problems are either minor or solved, then
release that as a our stable grimoire. Do this over a one or two month
cycle or something. Then while the next stable is being worked on some
other fixes will show up that might be needed/wanted such as security
fixes, at that point have a subset of machines/people test it, once they
mark it off have a new minor stable release. Basically we'll have a 4th
branch thats tagged off of test once a release cycle.

We just need someone to step up and maintain prometheus more intently than
I can, although as Ive said before, Im more than happy to be a resource
for how it works and why it works the way it does. We'll also need
someone to head up the release process, which could be the same person
as the prometheus maintainer. Its then just a matter of having a few
volunteers to go through the prometheus bugs and start submitting fixes.

With a cluster of 3-5 machines, distcc, and a shared ccache you can really
speed up prometheus (a year ago I was getting xfree86 to compile in
under 30 minutes on a 300mhz machine).

-Andrew

--
__________________________________________________________________________
|Andrew D. Stitt | astitt at sourcemage.org |
|irc: afrayedknot | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus | acedit at armory.com |
|Sorcery Team Lead | ftp://t.armory.com/ |
--------------------------------------------------------------------------

Attachment: pgp7glE4mQqcK.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page