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

Re: Release Cycle



Title: Re: Release Cycle

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



> Halving the seed rate in a field of wheat won't make the wheat ripen
> twice as fast. 

But breaking an ice cube in half does help it melt faster.

The question is which analogy is actually ... um ... analogous (or,
probably more accurately, how much each applies to this case).


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



Reply to: