stu at asyn.com
Wed Jan 19 03:57:47 UTC 2005
Trying to reset on some arbitrary calendar basis, based on the last
freeze, would appear to open Bugzilla up to an abnormally long
stabilization effort, causing problems.
What about the idea of "Freezing" 4 months after a release, allowing for
an estimated 2 month stabilization time, give or take some arbitrarily
long time like Bugzilla just experienced. During the freeze, the trunk
is frozen, no new development branch is created, to encourage people to
work on stabilization efforts. Basically, By not resetting the clock
until the release goes out, you solve the problem of having releases
stacking up, and you guarantee a suitable window for feature enhancement.
I thought I saw this suggested, and apparently hadn't been following
this thread closely enough, or missed why this wouldn't work.
David Miller wrote:
> Gervase Markham wrote:
>> "Remind me why delivering sooner than six months after the release we
>> just did is a good thing?"
>> I'm suggesting that we revisit that logic. One can make an argument
>> for "releases every X months", for most sane values of X, but I can't
>> see an argument for "freezes every X months". How is the date of a
>> freeze important? Surely it's the release date you are trying to hit
>> that's the important thing.
> But Nick's idea didn't say that.
> We advertise to everyone "we're releasing every 6 months".
> We make those dates be May 15 and November 15 every year.
> In order to meet those release dates, we freeze 2 months in advance,
> i.e March 15 and September 15.
> If things happen to get cleaned up faster than 2 months, then we
> release early.
> So the releases could, in theory, range anywhere from 4 to 8 months
> apart from each other, but will very likely stay pretty close to 6
> months anyway.
More information about the developers