Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Let's make Source Mage not suck!

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Let's make Source Mage not suck!
  • Date: Mon, 8 Jan 2007 07:58:57 -0800

On Sun, Jan 07, 2007 at 02:24:41PM -0600, Jeremy Blosser wrote:
> On Jan 07, Andrew [afrayedknot AT thefrayedknot.armory.com] wrote:
> > On Sun, Jan 07, 2007 at 10:52:49AM +0500, Alexander Tsamutali wrote:
> > > Users want to install operating system, install stable software and
> > > then they want to install only critical or security bugfixes (support).
> > >
> >
> > What users? How many? Where are they? How come no one else has said
> > anything?
>
> It's worth noting that this thread is not yet a week old and it's still the
> holiday season. Given the low level of activity recently it's entirely
> likely that not everyone has even seen this discussion yet. I'm *not*
> saying that's a reason to not move forward on these ideas but I don't know
> that an argument for consensus from people's silence is completely
> compelling right now.

Fair enough, although the thread has been quite active, so its not
unreasonable to think that some of the more active participants would've
said something. Also, people have already started work for this, which
provides some indication of support.

>
> > We have limited resources, you must accept we cannot please everyone,
> > given that others have shown support, or at least given silent approval,
> > that indicates that 2 weeks will fit some of our requirements and please
> > a fair number of people. If it didnt, then they wouldn't respond.
> >
> > > After some time passes they want to upgrade operating system, and i
> > > don't think they want to upgrade every 2 weeks, so support time should
> > > be longer (at least 6 month, better more than a year).
> >
> > First of all, who are these users? We need evidence.
>
> We hear from a decent number of users who do the 6 month / 1 year update
> thing, though we've never really accepted supporting that timeframe.

> According to
>
> http://ledger.sourcemage.org/users/statistic_live.php?select=openssh
>
> 6 of 41 machines (14%) are running openssh 4.3p1, which hit the grimoire
> 2006-02-01 and is older than what's even in the current stable. This isn't
> a lot of data (it would be nice if ledger could show the grimoire those
> boxes are on; does anyone know a way?) but it's what we probably have
> available.

Those were machines that have recently reported their setup, I hope?

>
> While people running stable in production are going to be the most
> critical cases (as you noted), we hear it from general workstation users as
> well.

Well, one has to ask why. Do they not update because updates tend
not to work? Because stable releases are infrequent? Or because they
prefer that way of doing things? Or some combination of factors?

I have machines I dont update, and I know when I do update them, things
may not work, Im okay with that. I think other users if educated,
will understand that tradeoff. So as you note below, its a matter of
communication.

In anycase, we're not preventing them from doing what they want, and we
give them some tools to make it easier. I just think what they want is
outside the range of what we can reasonably expect our developers to do,
right now.

>
> > I think we can say with confidence that many users are not pleased by
> > a stale 6-12 month old grimoire.
> >
> > I'll go one further and say that I think users will like short quick
> > updates once every two weeks rather than massive yearly ones. I dont
> > update many of my machines currently because the stable updates are
> > always so substantial.
>
> There's 2 majorly conflicting use cases here: there's people that want all
> the latest stuff and don't mind small, frequent updates, and there's people
> that cannot update very often for whatever reason and then have issues if
> the update is too substantial when they finally get a chance, or worse,
> they've missed some updates and we've pulled some of the transitional code
> and they can't do a clean update. There's going to be a range of opinions
> on where on that continuum we should put "stable"; some people think they
> deserve the bleeding edge even if running "stable", and some people won't
> even believe something that's been out only 2 weeks can fit a definition of
> "stable". Security updates aren't included in that discussion; most
> people accept those should get applied ASAP and if they disagree we dont'
> really care.
>
> However like you noted the bottom line right now has to be that:
>
> > We dont have a lot of resources, you need to keep that in
> > mind, no implementable plan will please everyone, I would go further and
> > say that no plan, implementable or not can please everyone.
>
> This is definitely true and I think in the end we have to take whatever
> approach works for our *developers* first, because as few as we are
> anything that won't work for them will mean we don't do any updating at
> all, and that pleases no one. But I do think that whatever we decide on
> needs to be communicated to our users so they can figure out how to manage
> themselves.

No argument from me on that. Communication is important.

>
> > Also, theres a subtlety here that you have overlooked. We dont support
> > intra-stable updates. However we provide archival versions of stable.
> > So someone could upgrade serially, one release at a time during one
> > "upgrade session".
>
> Where do we provide archival versions of stable? This is definitely a good
> way to address this issue, but to my knowledge we don't provide old
> grimoire tarballs right now. This is bug #11809; there it's primarily
> meant to address the "old versions of spells" issue, but we might extend it
> for this by making sorcery upgrade grimoire-version-aware warning people
> trying to skip too many versions that they should do it serially.

I thought we were doing this, I guess we're not, my mistake. Its easy
to do, I've done it with sorcery for most of my tenancy as component lead.

>
> A very related issue is that we don't currently have a solid definition of
> how long transitional code should stick around. It used to be two weeks,
> which we had to change when we got off the two week cycle, now it's loosely
> seen as 2 stable releases. We need to define that for the benefit of
> users. Something like the above recommended upgrade path would make this
> easier to define.

I dont have a good answer, and I dont want to pick one now. I'd like us
to try things out, and work out the finer details later based on what
we're actually capable of, not some goal we agree would make people
happy but no one wants to implement.

>
> > Many years ago, before "devel" was taken offline, we had a two week
> > release cycle. Devel became test after two weeks, test became stable
> > after two weeks. That was flawed because we didnt formally test test.
> > However a precedent exists for a two week cycle.
> >
> > Lastly, since I've been a part of this distro, we've always recommended
> > updating on a regular basis, regardless of the grimoire you chose.
>
> We do recommend it and always have but I think we can do our users the
> favor of defining "regular basis" and note risks they'll run if they go
> outside of that, especially since our own definitions have been changing as
> we try to figure out what works.

Agreed. I think as we get more comfortable with regular releases we'll
have better answers to these questions. Moreover, with regular stable
releases we'll be in a better position to evaluate the feasability of
longer term support. One step at a time.

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




Archive powered by MHonArc 2.6.24.

Top of Page