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 21:01:51 -0600

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

Fair enough, but sorcery is one product, while the grimoires each have a
lot of different components that may or may not interrelate, as you noted
below.

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

To me the obvious fix for this is to have the gnome spells themselves exist
as a branched repository. If the version of the gnome spell(s) trying to
get through "staging" were 2.6 and there was a problem with them, but
devel/test's "HEAD" was already to 2.8, you'd still have the 2.6 branch of
those spells to do fixes against in devel/test.

There's a meta-question here: Are the different grimoires each environments
containing various components that each have their own branches, or are
they all only branches of one component? I understand the appeal of the
latter, but if we're only allowed to have one branch of each spell for each
full grimoire branch, we're definitely going to be limited in the kinds of
QA we can provide per spell and for the grimoires as an interrelated whole.

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

The problem is when things get to stable without all their dependencies
making it with them; "dependencies" being either versions of other spells
or less obvious things. How new the problem spell is or isn't is
orthogonal to whether or not we correctly tracked what it needed to work
correctly in the environment(s) where it works.

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

Taking a staging environment that is identical to stable and then adding
one atomic upgrade to it and verifying everything works as expected before
promoting that unit to stable is still unit testing, it's just more
granular units. Sorcery is basically one component, release cycles make
sense there. Grimoires are a lot of components, each with their own
release cycles, and they don't necessarily need a meta-release cycle added
onto that.

One of the grand potentials of a source-based distro is that it allows
"release early/release often" to be true distribution-wide to the nth
degree. The kind of people that run this kind of distro generally want
their choice of when to upgrade a given spell, starting from the moment
it's reasonably available. Doing per-component tests and upgrades still
allows people to grab "today's stable grimoire" and pick their component
upgrades from there; doing biweekly cycles means they have to wait a while
between releases. It doesn't sound unreasonable to wait a little while,
but that will still cause most of the people that would use this kind of
distro to just end up living in test anyway. We can say "that's their
problem" but it means they'll start complaining about the exact same things
that started this conversation still happening in test, and we'll be stuck
dealing with either more fixes or just the complaints there.

Yes, people want to have their cake and eat it too, but isn't that why we
run Source Mage? :-)

> > 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 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 agree we're all talking about needing 4 environments. I don't really
agree that we're talking about the same 4 with different names, but there's
no real reason to argue about that. The things I'm calling out as
important are:

1) We shouldn't do changes in the last pre-stable environment, we should
have a way to do those changes in devel, with per-spell branching if
necessary (note this would also facilitate users running older versions
of spells, which there will likely be significant and increasing demand
for).

2) We shouldn't introduce release cycles into stable unless we absolutely
can't avoid them. I don't think it's that hard to avoid them, even
without (1).

> I work in software development and this is roughly the way things work,

And I work in code promotion and management, among other things. ;-) I'm
sure we both know what we're talking about. The environments I work in do
a lot of this business of lots of related/unrelated components needing to
coexist between various dev/test/production environments, so that's the
experience I'm speaking from.

Attachment: pgp6BsY7zYXb3.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page