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 16:55:59 -0800

On Fri, Feb 25, 2005 at 06:12:59PM -0600, Jeremy Blosser wrote:
> On Feb 25, Andrew [afrayedknot AT thefrayedknot.armory.com] wrote:
> > On Fri, Feb 25, 2005 at 02:47:22PM -0800, Eric Sandall wrote:
> > > 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.
>
> 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.

The process im illustrating is basically how sorcery is developed and
release, it works quite well IMO.

The issue comes up when the spell in pre-stable has a problem, lets say
it was a gnome spell which is currently (say) 2.6, and back in devel/test
there was just a big gnome update, so there all the gnome spells are 2.8,
maybe Im missing something, but I dont think youd want to push just one
2.8 spell in with the other 2.6 spells. Alternatively you could push all
the gnome spells in, but what if they're not ready, you'd never reach
a point of stability with the codebase your branched from? What if the
spell in question was glibc or gcc or something where the version in
test/devel is just not ready for general consumption. The only other
option is to hold back development in test/devel branches, which also
gets you nowhere because then we'd loose our bleeding edgeness and
people would just have to pocket their updates which is certainly
counter-productive.

The problem is, we want it new, and we want it stable, and we want both
right here right now.

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

Well, you cant have anything with guarenteed stability of any sort unless
you have some sort of fixed release process where everything is tested
as a unit. I didnt say anything about changing the way test/devel work
and if one wants to get away from release cycles go there, if you want
some compromise of stability use stable. Sorcery has release cycles.

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

In this model we're basically renaming my pre-stable branch "test",
and renaming our dual branch test/devel model "devel". If you re-arrange
the names and account for updates in devel you dont want its almost
exactly the same.

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

I think whats going on is we have three branches, but we really need four,
and as a result we end up putting our three branches in different spot
in-between the four branches we really need, then debating over where
in that grey area we want them to be.

So i'll pick new names, we'll call them what we want:

A: anything goes here, it can be totally broken, and used as a testing
ground for changes that should only be moved to the next branch as
a whole (like an update to all of kde or gnome).

B: this branch isnt anything goes, but has a semblence of stability in
that things that developers are reasonably sure work but havent been
tested by a sufficiently large crowd.

C: this branch is a proving ground for fixes here we try and make sure
the entire thing works as a whole

D: everything in this branch has been sufficiently tested as a unit any
major bugs have been taken care of, it may be a month or two behind in
versions but at least we know it works.


So the problem is, we want three branches and we're putting them in the
gray areas between A B C and D, and as a result we all have different
spots in that gray area where the branches lie.


I work in software development and this is roughly the way things work,
although theres a whole bunch of A style branches people use, and theres
a C for every major release, and a D for every release, but its basically
the same.

In sorcery we have a 4 branch structure just like this and I think
it works quite well. Theres a place to do insane destablizing work,
a place for new stuff we think is ready for brave people's consumption,
a place where we try and work out the kinks by having a larger audience,
and finally a place for bona-fide releases that the general public can
use, and if the previous step works right, is also stable. However in
sorcery we call these "proj/projX" (for which there can be multiple X's),
"devel", "test", and "stable".

Just my thoughts on expanding the idea sandalle had, either we redefine
test and devel and add another branch on top, or insert a branch between
stable and test, you end up in the same place.


-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: pgpohECFt8Gcp.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page