[SM-Discuss] "staging" grimoire instead of devel for development spells as opposed to WIP spells?
afrayedknot at thefrayedknot.armory.com
Fri Feb 25 23:11:45 EST 2005
> 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
One product with a whole bunch of partially related features...lets not
be too hasty to say sorcery is overly simple, although your point is
well taken, and I more than agree that grimoires are far more complex
> 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.
Well, thats basically the issue of having multiple "A" environments
which all eventually stabilize and filter down into a single grimoire
at some point. Theres no reason why we cant have multiple devel
branches for different purposes other than it puts unnecessary load on
our repository. Someday we may migrate to a more distributed revision
control system which will enhance the feasability of this idea.
> > 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.
Realize of course that realisticly we cant have a single atomic upgrade
to our stable grimoire, the tag, test, fix, retest process is going
to take a non-zero amount of time to complete. Trust me when I say its
Like I said, given our resources its an intractable problem to ensure
one spell update didnt break anything else, hence the need for a release
cycle between the "B" and "D" codebases. Like I said before, it just
seems a lot like you're trying to move B closer to C and D closer to C,
then say we dont need C. We need the C phase in some way shape or form.
> 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? :-)
Well, I can tell you right now some people want bleeding edge, and some
people want stable, and theres no way we're gonna get both at exactly the
same time. The old devel/test/stable idea was basically to have a scale
between stability and bleeding edgeness, but it just dont work that way,
stable ends up just out of date.
The latest/greatest release early/often notion is embedded in whats
currently our test grimoire, or what would be known as "B" in my
description. You (the user) can do selective upgrades of things you
want, you get the latest greatest stuff and its released every 6 hours,
and updates come in throughout the day.
But theres also long since been a desire to not have to think about
individual upgrades and wanting to just say "system-update" and have it
all work. Its impossible to guarentee that everything will work in B,
but in D we want to at least try and be able to guarentee that. We want
to have a stable grimoire that as a whole is solid. The only way to do
that is to test it as a whole, and that takes a non trivial amount of
time, hence C.
> > > 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
Okay, so we have a branch off of the codebase C where we make changes,
then we backport them to A then B, or B then A, if they still apply, or if
the fix is B push them directly into C, then sync the C sub-branch(es)
up, note that C sub-branches can just be people's uncommitted sandboxes.
I think the point needs to be made that C and B (and A with it) are
effectively disjoint tracks of development once C is pulled off of B
(in my model). B can continue without needing to depend on C, if they
dont diverge then great, but it shouldnt be a restriction. Also, per
spell branching I think provides too much overhead and complication,
we end up basically with the same result I think, just we put different
weights on spells, i say just branch the whole thing and use what you
need, you say branch individual things from the head-of-line.
> 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).
After nearly three years with the project and knowing how long it takes to
run prometheus on the entire grimoire and the corner cases it'll find,
we cant avoid a "release cycle" with what we're trying to accomplish (a
stable grimoire). We've tried to avoid it for three years and its just
not gonna work.
|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/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20050225/34cb7679/attachment.bin
More information about the SM-Discuss