Re: Review of release criteria?

[Benjamin Kosnik <bkoz at redhat dot com>]

> Formally, no -- at least I don't plan on doing that.

I'm a bit pissed about this.

There are a lot of people who worked very hard on this release who are
not on the SC and would like to know what is up. I consider myself one
of these people. Part of your duty, as I see it, as release manager
involves communicating with developers, trying to figure out what went
wrong (and how it can be fixed) and what went right (and should be
made part of the process.)

I think public feedback on the release very important. 

So, in the interest of having a public review of gcc-3.0's development
and release process, here's my take on the release.

The original criteria for gcc-3.0 can be found here:
http://gcc.gnu.org/gcc-3.0/criteria.html

I'm speaking only to the C++ portions of the criteria.

1) Functionality
	a) C++ ABI 
	??

	b) GCC Support Library
	What else has to be done on this?

	c) C++ Standard Library
	What remains to be done:
	versioning symbols/headers
	issues with multi-libs and the testsuite/mknumeric limits
	solaris additional IO fails
	wchart_t io/named locale	

In general, C++ is validating well against commercial validation
suites and I'm pretty pleased.

2) Applications (C++ testing)
	a) specified
	pooma-2.3.0 and stepanov_v1p2

	b) actual
	blitz-20001213
	http://gcc.gnu.org/ml/gcc/2001-06/msg00195.html

	boost 1.22.0
	http://gcc.gnu.org/ml/gcc/2001-06/msg00196.html

	root 3.01.00
	http://gcc.gnu.org/ml/gcc/2001-06/msg00437.html

	pooma-gcc
	http://gcc.gnu.org/ml/gcc/2001-06/msg00438.html

	mtl 2.12.2-19
	http://gcc.gnu.org/ml/gcc/2001-06/msg00874.html

	qt 2.3.0
	http://gcc.gnu.org/ml/gcc/2001-06/msg00875.html

	ACE 5.1.17
	http://gcc.gnu.org/ml/gcc-bugs/2001-06/msg00689.html

	c) recommendation: Future releases of gcc-3.x amend the
	criteria to include all the C++ libraries included in
	b). Furthermore, we need these sources bundled into a separate
	testsuite, and automated runs made on a nightly basis, with results
	hopefully posted to gcc-testresults.

3) Platform support
	a) specified
		(primary)
		alpha-unknown-linux-gnu 
		i686-unknown-linux-gnu 
		sparc-sun-solaris2.7 
		powerpc-ibm-aix4.3.3.0 
		mips-sgi-irix6.5 
		hppa1.1-hp-hpux11
		(secondary)
		hppa1.1-hp-hpux10.20
		i386-unknown-freebsd4.2 
		armv4l-unknown-linux-gnu
		powerpc-unknown-linux-gnu
		i686-pc-cygwin 

	b) actual
		(primary)
		alpha-unknown-linux-gnu 
		i686-unknown-linux-gnu 
		powerpc-unknown-linux-gnu
		i386-unknown-freebsd5.0
		alpha-unknown-freebsd5.0
		mips-sgi-irix6.5 	
		sparc-sun-solaris2.8	
		(secondary)
		i386-unknown-freebsd4.3
		alpha-unknown-freebsd4.3
 		alphaev56-dec-osf5.1
		hppa1.1-hp-hpux10.20
		hppa1.1-hp-hpux11
		mips-sgi-irix6.2
		sparc-sun-solaris2.7
		sparc-sun-solaris2.6
		i686-pc-cygwin 
		(not working)
		armv4l-unknown-linux-gnu
		powerpc-ibm-aix4.3.3.0 

	c) recommendation: There seem to be some issues with C++
static linkage and non-ELF platforms, sjlj exceptions on cygwin and
arm, the c++ library testsuite on solaris, and issues for threaded
configurations. In addition, the use of non-GNU make, ld, and as seem
to change testresults and or build success on some platforms. Use of
different binutils and make should be detailed.


4) Compile-Time Performance

	There were no C++ tests for compile-time performance, yet
there's been a considerable regression. A large part of this is the
new, tempalatized C++ library, but I'm not quite sure if
non-templatized code compiles faster, or slower, or by what metric
this should be measured. I think something should be put into place
now, so that 2.95.x and 3.x can be compared, and that developments
like PCH can be meaningfully compared.