Public SourceMage Discussion List

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

On Sun, Jan 07, 2007 at 06:57:51PM -0600, Daniel Goller wrote:
> On Sun, 07 Jan 2007 09:53:58 -0800
> Andrew <afrayedknot AT thefrayedknot.armory.com> wrote:
> 

First, the definition of support needs to be clarified. When I say
support, I mean that
1) the spells we said work, worked to the best of our knowledge at release 
time
2) upgrading to the current stable should work
3) when running an old grimoire you can cast spells from
the current grimoire, assuming they're supported (pt 1). Doing so may
require a partial upgrade if there are dependent updates.

Second, there is a distinction between support and how long it works
anyway. A car typically continues operating even after the warranty
expires. So, just because we dont "support" it, doesnt mean it wont work.
The world doesnt disintegrate when you do something unsupported, it just
means "if it doesnt work, its not our problem"

The main issues for us with support are transitional code, and
dependencies on specific (newer) library versions. Also urls go bad,
but we have fallbacks, checksums go bad, but thats solvable.

Im not really sure what you meant by support, so Im just going to respond
based on my definition.

> 
> 
> I guess there is a simple 2 topic issue here, one is how often we want
> to release something and how long we want to support it.
> 
> If say we do want to release something monthly or quarterly or semi
> annually, how long do we support each version?
> Say i install 0.8 today, and with a 2 week cycle, you will be on 1.2 in
> 8 weeks, how long before bugs, that i file against 0.8, will be closed
> with "unsupported release".

If the bug still exists in 1.2 then no, it wouldn't be closed.
If the bug was fixed in 0.9 the fix wouldn't be backported, but you
could cast it anyway.
If the bug was fixed in some future release beyond our support period,
but you could try casting it anyway, it just wont be supported. Chances
are, it'll work anyway...

If it doesnt get fixed for them, or the fix doesnt work due to support
issues, does that mean the user is going to say smgl sucks and go install
something else? I dont know. Probably not, maybe if they're on the fence
already. Lets face it, most distros have problems, many users come here
because they found their distro of choice had too many problems, we
just have to have either less problems, or some other incentive to stick
around. I think the way our distro works in general, and what its capable
of is a strong incentive for most.

If a user is deliberatly not updating, I would say they fall into two
categories:

sys-admins with machines in production
users who dont have time to update

sys-admins probably have the know-how to work around these issues,
either they'll fix the spell, or they'll work out something with a
partial upgrade, or whatever, they're intelligent, they can figure it out,
its not "rocket science".

Non-updating users can use the lazy updates feature in sorcery if they
really cant do full updates. I have some machines I dont update regularly,
I do this on them instead, its not been a problem, even though I sometimes
will be a few grimoires behind. Again, this outlines the distinction
between us supporting something, and it "working anyway".

Is this perfect? No.
Can we realistically solve these problems for them given our resources? No.
So we give them tools (scribbler, lazy updates) to do what they want.

> If you want 2 week cycles and agree we should have support cycles of 6
> or 12 months (or longer), how do we manage support for the large number
> of stable grimoire versions out there?

We dont remove any transitional code until the support period is over,
and within our resource constraints ensure that upgrade related bugs
are fixed in the current grimoires. This is what we've always done.

> You might say "we take care of the bug against the version of the app,
> in all supported grimoires in those released in the last [6|12] months"
> What we do not know is that this only happens to users in grimores 1.2,
> 1.3, 1.4 (oldest supported is say 1.0 and newest would be like 2.3 or
> 3.6 based on support lengths) since only in those a dependency has a
> version that triggers the bug, uncommon enough to not have been caught
> by us during our testing.

This sounds to me like backporting, and we're not doing that right now. In
fact,the only reason we pull so much into stable is because our release
cycles are way too long and users get frustrated when a bug is fixed in
test and not "stable".

> I just don't think there is much we can do to script figuring out what
> is where, so quarterly releases are easier to deal with than bi-weekly
> ones. since there will be less supported stable grimoires in that
> timeframe.

We could script testing it, but no one will. Besides we lack the resources
to fix stuff this way. Oh well.

> 
> 3 months is a pretty reasonable in my opinion.
> 
> Or, at least let it work smoothly in a 3 months cycle, before
> tightening up the screws and doing it by-monthl, then monthly.

3 months is too long. If we walk away from this saying "release in three
months", its not going to work. I can guarantee it. We'll look at that
timeframe and try to fix a bunch of stuff, then after a few weeks people
will get bored, distracted, whatever, and everything will grind to a
halt. Again. People will complain about bugs not fixed in stable,
and integration requests will stack up. This is where we are now.

Three months makes it feel like a side-project, two weeks puts it in the
fore-front and means that we cant fix a whole lot in any one release, but
not much changes either. Thats a good thing. For both us (less work) and
for users, smaller ugrades have less potential for breakage than big ones.
Users can upgrade by using each grimoire in sequence, so its only a
minor inconvenience with a technical solution.

> 
> Traveling down this path we will see at which point people start to
> feel it puts an undue strain on them to support that cycle.
> Might go down smoother than users getting biweekly for 2 months and
> then seeing quarterly again.

The point was that it would be easier for our developers. The plan only
requires a minimal amount of work from everyone, one or two spells,
not a whole section, not every bug prometheus finds, just a few spells,
mostly spells we already know work. Its easier for users because they have
predictable release cycles with only a few updates. Currently they have
an unpredictable cycle with huge numbers of changes. Many upgrade
scenarios haven't been tested. Theres more chances for failures with a
long cycle because more changes are mixed together.

Certainly none of this prevents anyone from making a longer-term stable
release. Many spells will probably continue working long after our
support period anyway. We just lack the developer interest in creating
something like that. Certainly some people are interested in *having*
it, but nobody wants to *make* it. We have to work with the resources
we have, and with what people will do.  Given our platform is "work on
what you want", theres not much to work with.

This isnt a panacea, it wont be perfect, I think its a mistake
to strive for perfection, and thats what it seems like we're doing.
There are lots of problems this wont solve, many of which we cant solve right 
now. Things will break. The world doesnt end when they do.

What I hope, is that this makes things better. Once we get there, we'll
have better footing with which to improve things further. But we cant
do it all at once.

We need to do *something*, I contend we do something that has low chances
of failure.

-Andrew


-- 
_________________________________________________________________________
| Andrew D. Stitt  | acedit at armory.com    | astitt at sourcemage.org | 
| irc: afrayedknot | Sorcery Team Lead       |      ftp://t.armory.com/ |
| 1024D/D39B096C   | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C  |
-------------------------------------------------------------------------