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: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • 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 18:48:10 -0600

On Feb 25, Eric Sandall [eric AT sandall.us] wrote:
> Quoting Jeremy Blosser <jblosser-smgl AT firinn.org>:
> > On Feb 25, Andrew [afrayedknot AT thefrayedknot.armory.com] wrote:
> > 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]).

Right... you typically need a staging separate than test because test is an
"unclean" test environment (for the reasons you described), while staging
is "clean".

> 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).

Yes, I agree you'd want human intervention, though the automated process
would probably work too, just not as efficiently. Sounds like maybe we
need a "Release" Team.

> > > 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.

Yeah... and since staging should always be "stable + whatever spells are
currently being built to verify they work", there's no reason anyone should
want to use that as a grimoire, except for QA purposes (the above "Release"
Team/task force).

> If this sounds like a good plan then we should get Prometheus working (any
> volunteers? ;))

I'm new here, does the project need things like this more or less than
it needs section maintainers?

Attachment: pgpWvSjYmaDdq.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page