Greg Stein wrote:
> On Tue, Jan 27, 2009 at 15:15, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> ...
>> We always roll at least 2 release candidates, one at the beginning of the
>
> Then that first "candidate" is NOT a candidate.
>
> Get real here. A "release candidate" means "we think this is ready to
> go." You can't just go and make up new meanings. Call it a prelease
> build or something. But it is NOT an RC if you are baking a second one
> into the schedule.
Sure the first one is a candidate: if there aren't any changes made during the
soak, then we create the final from that one. If there are changes (such as
translation updates, minor bugfixes, etc.) we roll the extra RC. That's been
the policy from time immemorial.
From HACKING:
"At the beginning of the final week of the stabilization period, a new release
candidate tarball should be made if there are any changes pending since the last
one. The final week of the stabilization period is reserved for critical
bugfixes; fixes for minor bugs should be deferred to the A.B.1 release. A
critical bug is a non-edge-case crash, a data corruption problem, a major
security hole, or something equally serious."
I do *not* want to get into the scenario we got into with 1.5: "whoops, found
another bug, time to roll rc28". The current "pre-soak" state on trunk is
hopefully helping that not to happen.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1059284
Received on 2009-01-27 16:41:38 CET