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: Eric Sandall <eric AT sandall.us>
  • 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 16:28:09 -0800

Quoting Jeremy Blosser <jblosser-smgl AT firinn.org>:
> On Feb 25, Andrew [afrayedknot AT thefrayedknot.armory.com] wrote:
<snip>
> > 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.
>
> From a code promotion perspective you usually don't want to be making
> changes in the staging area and then backporting them, you want to be
> making changes in the dev area (even if it doesn't look broken there) and
> then promoting them in the staging area to confirm they're fixed. If you
> backport you *will* miss pieces and just have to go through more iterations
> to get it all to build, or worse yet will promote something as working when
> it isn't going to work in a clean environment.

What I was proposing was the fixes go only in this direction: devel -> test ->
stable (though sometimes devel <-> test is done as devel isn't always in sync
with test and ready to be integrated [e.g. the gcc/glibc work]). A "task
force"
would be nice to look at the Prometheus output (to have human input into the
process) and (hopefully) make smart/educated decisions on what happens to
failed packages (some may just need to remove another update to have the rest
of the failed packages work, instead of removing all of them).

> > 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.
>
> The phrase "release cycle" makes me nervous. ;-) I think a lot of people
> come
> to source mage to get out of the release cycle treadmill (yes, even a rapid
> one like the one discussed here).
>
> It seems to me the way sandalle described it is simpler and pretty much how
> this problem is normally solved in software development. You basically
> have 4 environments:
>
> 1) Devel, anything goes.
> 2) Test, developers promote things here to see if they work and just try
> stuff out.
> 3) Staging, developers promote things here when they believe they work and
> are ready for stable. This environment looks 100% like production does,
> except for the changes being staged. NO CHANGES HAPPEN HERE. If
> anything fails it is reverted and has to be fixed in devel/test, then
> try again (think atomic commits).
> 4) Stable, things are promoted to here once they pass staging, usually
> automatically. If staging is done correctly, there are never any
> surprises when things get to stable.
>
> I think this is what sandalle described, with the staging environment tests
> and pushes to production automated and everything still getting promoted
> per spell after 2 weeks in test (if they work). It's also similar to what
> swoolley described, except he was reversing the use of the terms staging
> and test and wasn't formalizing it as much.

Yes, pretty much. :) My "staging" area wasn't one that would be publicly
released, but only available to the machine(s) doing the Prometheus checking
of
what is queued to go to stable.

If this sounds like a good plan then we should get Prometheus working (any
volunteers? ;)) and some machines "donated" to working on this (we can assign
sections to a machine for testing so that it's "distributed" across several
networks).

Also, if we do think this is a worthwhile endeavour and if the "final" idea
above (e.g. what I was describing and Jeremy clarified) works for everyone
(further discussion is encouraged, of course ;)) then I'd like to know if this
is something we'd want done before or after our 1.0. Yes, we try to keep from
adding items to our pre-1.0 list, but we also want to have our 1.0 be as
flawless as possible and the proposed methods would certainly help to ensure
that (as the ISOs use the stable grimoire).

-sandalle

--
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




Archive powered by MHonArc 2.6.24.

Top of Page