sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- 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: Sun, 7 Jan 2007 09:53:58 -0800
On Sun, Jan 07, 2007 at 10:52:49AM +0500, Alexander Tsamutali wrote:
> On 06.01.2007 00:00:50, Andrew wrote:
> > On Fri, Jan 05, 2007 at 09:52:44AM +0000, Juuso Alasuutari wrote:
> > > On Friday 05 January 2007 09:23, Thomas Orgis wrote:
> > > <snip>
> > > > Then, let's get that stable-0.6 out and start the next cycle with
> > a
> > > > real schedule that is fulfilled (a month, two?).
> > >
> > > So what would the optimal release interval be for us?
> >
> > I think the faster the better personally. I want to shoot for about
> > two
> > weeks. I think thats do-able. If it isnt then we're taking too
> > many spells. Shorter cycles are better for two main reasons:
>
> I think there is almost no point in 2 week release cycle.
I'd appreciate it if you could respond to the remarks in support of
a 2 week release cycle. There were many points supporting it, and to
say there is no point without refuting any of those points, and only
providing a hypothetical without any numbers or evidence of severity is
not a strong argument. Sorry.
I am certainly open to the notion that 2 weeks is pointless. But to provide
a convincing argument you must either refute the arguments in favor
of it, or, justify why the issue below takes precedence over all other
requirements and resource constraints. I think thats a fair thing to ask.
> 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?
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.
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.
> If we release
> often, a lot of stable grimoires appears and we cannot provide support
> over long period.
It would have been preferable to know this requirement before we went
into the planning phase. I had made the assumption that because you
started this thread, you were going to respond more frequently.
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.
The goal is to please a good subset of users with the resources we
have. That in-turn will lead to more resources, which makes it easier to
please more people. Not everyone will be happy, you have to compromise. I
see no attempt at all to compromise in your 6 month proposal.
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".
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.
--
_________________________________________________________________________
| 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 |
-------------------------------------------------------------------------
-
Re: [SM-Discuss] Let's make Source Mage not suck!
, (continued)
- Re: [SM-Discuss] Let's make Source Mage not suck!, Eric Sandall, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Alexander Tsamutali, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Andraž 'ruskie' Levstik, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, seth, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Andraž 'ruskie' Levstik, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, seth, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Andrew, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Alexander Tsamutali, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Andrew, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, seth, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Andrew, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Jeremy Blosser, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Daniel Goller, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Eric Sandall, 01/08/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Jeremy Blosser, 01/09/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Arjan Bouter, 01/10/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Andrew, 01/08/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Jeremy Blosser, 01/08/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Daniel Goller, 01/07/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, Andrew, 01/08/2007
- Re: [SM-Discuss] Let's make Source Mage not suck!, S. Barret Dolph, 01/08/2007
Archive powered by MHonArc 2.6.24.