Re: Stable release state

[David Kastrup]

"Phil Holmes" <address@hidden> writes:

> ----- Original Message ----- 
> From: "David Kastrup" <address@hidden>
> To: "Phil Holmes" <address@hidden>
> Cc: "Werner LEMBERG" <address@hidden>; <address@hidden>
> Sent: Saturday, April 06, 2013 3:26 PM
> Subject: Re: Stable release state
>
>
>> "Phil Holmes" <address@hidden> writes:
>>
>>> At present, we're actually premature in proposing a freeze to make
>>> ready for a release candidate.  We have a number of outstanding
>>> critical bugs and regressions which need fixing before we go anywhere
>>> with a new stable release.  So, currently, step one is to reduce them
>>> to zero.  Step 2 is to propose and agree a development freeze.
>>
>> Tackling step 1 and step 2 in this order was seminal for 2.16 taking
>> a year longer than anticipated.
>
>
> In that case, we need to be more active in getting rid of criticals
> and regressions.  Are you proposing we ignore them?

I am rather proposing not to consider them the perfect excuse for
keeping to shove new material into master, material that comes with its
own share of criticals and regressions.

The usual course of release planning involves _first_ freezing
development, _then_ reducing critical problems and regressions to a
release-compatible level.

For an example of how this works, see
<URL:http://gcc.gnu.org/develop.html>.  The important thing to note here
is the final stage 3 before branching:

    Stage 3

    During this two-month period, the only (non-documentation) changes
    that may be made are changes that fix bugs or new ports which do not
    require changes to other parts of the compiler. New functionality
    may not be introduced during this period.

Also check out the rationales for various policies.  Even while our
active team is smaller than that of GCC and has quite fewer fulltime
developers, the main strategies are quite applicable.

-- 
David Kastrup