Public SourceMage Discussion List

[Daniel Goller <dgoller AT satx.rr.com>]

On Sun, 07 Jan 2007 09:53:58 -0800
Andrew <afrayedknot AT thefrayedknot.armory.com> wrote:

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



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

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.

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.

Daniel

Attachment: signature.asc
Description: PGP signature