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: Arwed von Merkatz <v.merkatz AT gmx.net>
  • 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: Sat, 26 Feb 2005 13:32:25 +0100

On Fri, Feb 25, 2005 at 04:55:59PM -0800, Andrew wrote:
> 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.

I think backporting from the staging area is the way to go, as the
problem might not even exist in the devel area anymore. Remember that
this staging area will diverge from devel as it takes time to test it.

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

I agree to that. To have a really stable stable grimoire we need some
sort of release cycle, and I don't think users won't be happy with that.
The way I see it is that users who always want to stay close to the
bleeding edge currently use the test grimoire and update often. Users
who just want a working system update much less frequently. One of my
friends using SMGL updates at most once per month, and that's probably
quite common for users of the stable grimoire, so a release cycle of
about two weeks would probably not even get noticed by many users -
except for the added stability it brings.

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

Exactly. When we decided to not have devel as a normal public grimoire
anymore it was because we wanted a branch like A where we can work on
really unstable stuff. And that includes stuff like beta releases of
gnome/kde/xfce in my opinion.

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

I like that four branch structure, with a release team and prometheus
working on branch C. Inserting a branch between test and stable for C
would probably be easier at A and B match our current devel and test
pretty closely.

--
Arwed v. Merkatz Source Mage GNU/Linux developer
http://www.sourcemage.org




Archive powered by MHonArc 2.6.24.

Top of Page