Re: Freeze timing and questions

[Mark Mitchell <mark@codesourcery.com>]

--On Saturday, December 15, 2001 08:57:32 PM +0000 "Joseph S. Myers" 
<jsm28@cam.ac.uk> wrote:

> According to develop.html, GCC 3.1 Phase 2 ends Dec 15 2001 (today) and
> Phase 3 begins where

In a rare nod to the historical "weekend" custom, I took Saturday and
Sunday off.  I would have posted a message this morning, but since you
beat me to it, I'll just reply to yours.

>    During this period, the only changes that may be made to the compiler
>    are changes that fix bugs. New functionality may not be introduced
>    during this period.

Yes.

The point is to spend the next couple of months stabilizing the compiler.
That means that we find important bugs, from GNATS or elsewhere, and
try to fix them.  It's OK if they're not regressions; now is a great
time to fix that horrible bug that's been annoying you since 1996.  We
are now, however, focusing on quality -- not new items for the 3.1
release announcement bullet list.

> (a) What's the exact time of the transition to Phase 3 (feature freeze)?

11:59 PM, GMT -0800, Monday, Dec 17. 2001.

> (b) What's the list of important targets for 3.1?

I do not have an answer to this one.  I do not believe the SC has
come up with a list, which is too bad.  Unless we here otherwise,
I guess we will have to stick with the 3.0 list.

> (c) Is there any further guidance on what classes of changes are
> acceptable during this period, in particular about the following:
>
>   (i) Changes that fix known/reported bugs, but where a proper fix
>   involves new functionality (e.g. implementing a language feature that
>   was broken and only worked partially / by accident).

On a case by case basis.  Anyone can approve the change, but we should
be looking for relatively minimal changes to solve problems.

>   (ii) Deliberately removing or deprecating undocumented extensions, or
>   making the compiler reject code it ought to reject but hadn't previously
>   checked for.

That is OK, except that people might decide that the extensions were
important, and should be documented, not reported.

>   (iii) Deliberately removing or deprecating documented extensions.

Case by case basis.  We should avoid doing this unless it is really
necessary; we are trying to create as few disturbances as possible.

>   (iv) New CPU ports (which don't have the risk of affecting other code).
>
>   (v) New OS ports for already supported CPUs.

Both OK, as long as they do not affect other code.

>   (vi) Documentation work (possibly with associated Makefile changes) that
>   makes improvements that are not bug fixes.

Always OK.

>   (vii) Fixing currently bitrotten and disabled front ends (i.e. Chill, if
>   our volunteer to fix it gets the time to do so).

This is OK, but at this point I think it is unreasonable to actually
support Chill in 3.1; its status would be equivalent to the KDE patches
in the contrib/ directory.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com