Public SourceMage Discussion List

["S. Barret Dolph" <wheds8 AT ms66.hinet.net>]

I hope things can be done to improve Source Mage so that I have the
time to use it. I installed Source Mage on a box that was falling apart
and was quite excited to have it working albeit for a short time.
Unfortunately, I don't have the time to fiddle but if Source Mage can
be just a little more stable I will happily move back. That is why I
continue to be on the mailing list. 



On Mon, 8 Jan 2007 07:34:04 -0800
Andrew <afrayedknot AT thefrayedknot.armory.com> wrote:

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