[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Release Cycle

Title: Re: Release Cycle

Aneurin Price wrote:
> On Tue, Feb 3, 2009 at 6:24 PM, Barclay, Daniel <daniel@fgm.com> wrote:
>> David Jardine wrote:
>>> On Tue, Jan 06, 2009 at 12:28:44PM -0800, Ken Teague wrote:
>>>> Barclay, Daniel wrote:
>> ...
>>> Well, maybe I'll prove to be understanding neither of you, but the
>>> point seems to be that you can't 'force' the maturity of a package.
>> I wasn't talking about trying to force the maturation of any changes to go
>> faster; I just meant dividing the changes into two (or however many) groups
>> so the first group could be implemented, "matured" and released before the
>> second group got started.
>> That shouldn't increase the _explicit_ development, testing, and fixing
>> effort required.  (Of course, as I said, there is also the additional
>> (presumably significant) overhead of making and tracking an additional
>> release in the middle.)
>> On the other hand, that division admittedly does reduce the _time_ during
>> which a change group is implicitly tested by being used.  (Instead of
>> having both sets of changes being tested for duration D, each gets tested
>> for only duration D/2).
>> So I guess that question is how significant that testing duration is
>> (compared to the number of people implicitly testing, etc.).

> It sounds like what you are advocating is for the freeze to begin, say,
> six months after release. Is that correct?

Yes (not necessarily that exact length of time, but yes, something shorter
that currently).

 > So the question really would
> be: what's the shortest amount of time from release N to freeze for N+1
> that can be justified given the overhead of releasing, and I think the
> answer to that will always be at least somewhat subjective.
> Nye
> (PS: FWIW, it's my *personal* belief that the freeze for Lenny should
> have been somewhat earlier, but on the other hand we already seem to
> have reached the point where the time from freeze to release is a
> large fraction of the total release cycle, and do we really want that
> proportion to be bigger?)

If the time until the freeze is reduced, fewer changes would be incorporated
before the freeze, so the length of the freeze hopefully would decrease too.
If it does, then the proportion of time in the freeze wouldn't necessarily
increase.   (Of course, the freeze length might not decrease proportionaly.)

(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]

Reply to: