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 17:33:16 -0800

Quoting Andrew <afrayedknot AT thefrayedknot.armory.com>:
> On Fri, Feb 25, 2005 at 06:12:59PM -0600, Jeremy Blosser wrote:
<snip>
> > 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.

Ahh, very true. So it'd be more devel -> test -> stable, but with fixes going
devel <-> test <-> stable, depending on how different the branches were? That
sounds reasonable (and I'm not sure why I didn't get it the first time you
said
it, sorry).

<snip>
> > 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 believe most people would be okay with a release cycle for stable (e.g. a
new
stable is generated every two weeks [or however often our Prometheus/Release
Team can test a stable stable ;)]).

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

Sounds good, then. :)

> > 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, I like this reasoning, but am leary of making our "C" branch available
to the general public (since its only purpose is for a team or program to test
as a unit and verify to be brought into "D"), just like we have devel where it
is (even after explaining to people why we won't make it generally available,
we still get complaints, hence my initial concern regarding another "branch").

So, if we can keep "A" and "C" safe from our users and only Officially produce
"B" and "D" tarballs (tarballs/access for "A" and "C" can be made available
for
those needing/wanting it for helping to test) then I'm all for doing an
intermediary branch "C" for the unit testing (I also like the idea of testing
stable as an entire unit since I think most of our stable problems come from
our current method of bringing in whatever seems stable at the time into the
mix).

-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