On Wed, Mar 19, 2003 at 10:01:07AM +0100, Matthias Klose wrote:
> [CC ing the other GCC people as well, not debian-gcc, as this started
> with private mails. Feel free to move it's over there]
Moved to -gcc. Happy fun multi-posting!
> Randolph Chung writes:
> > tbh hppa would benefit from going to
> > 3.3 too because of much better c++ support, but.... i thought we were
> > trying to move away from each-arch-have-a-different-default-gcc-version
> > situation that we had in woody.
> I don't see anything wrong with this. We have architectures, where
> this move was too early.
Having different gcc versions should definitely be the exception, not the
rule. If we've got problems on some architectures, we should be looking
to make sure they're fixed upstream in the latest stable release, and
we should be shipping the latest stable release.
> > In any case, the concern is that let's say we want to ship sarge in
> > a month (please don't laugh :-), then we will have half of the archive
> > built using 3.2 and half using 3.3. Even if they are 100% compatible, it
> > would mean everyone has dependencies on two compilers installed on
> > their system. yuck.
> IMO 3.3 should be a release goal for sarge, like glibc-2.3 is/was.
We should be shipping the latest stable upstream release, wherever
possible, and making sure that any problems that appear in our use are
fixed in Debian and upstream.
> > > I am not aware of any problem.
> > the problems are more from a distribution/release management point of
> > view. <shrug>, if aj is ok with this then i will just shut up.
> It seems we have a communication problem with our release
> management. Doesn't aj get our mails or read debian-gcc?
I'm not remotely up on how the toolchain works, and I don't like to
randomly talk about things that're above my head.
There are two issues: making sure you get the latest version tested and
working (by getting new versions of gcc tested on multiple architectures
and seeing if it builds all our packages on each arch and so on), and
making sure you don't block everyone else's development and testing
(by having a buggy gcc in unstable) in the mean time.
I presume those've been mostly addressed by gcc-snapshot already.
> The move of 3.2 to testing despite rc reports for m68k even without a
> note comes to mind.
gcc-3.2 was updated in testing, and gcc-3.3 was added to testing because
they were the major hold up at the time, and I heard secondhand that
you were about to start making things depend on gcc-3.3 on multiple
architectures any day now. Doing that sort of thing usually results
in a similar hold up to what's happened with glibc these past months,
and with the increased dependence on libgcc1, the gcc packages have a
similar effect. Having a broken compiler in testing doesn't do a lot
to effect an architecture: everything's built from unstable, so if the
toolchain there is unreliable, the architecture's unreliable.
> Release management happens behind the scenes,
> which I'm not happy with.
So does gcc management, big deal.
If you don't see why this is, you're invited to comment on -devel
about the plans for the 3.2 v 3.3 ABI issues, and enjoy the wonders
of transparency.
> PS: aj, IMO release managers are dictators, but it is said that some
> of them are benevolent :)
Yes, and it's often said that everyone's a critic too. Lay off.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Dear Anthony Towns: [...] Congratulations --
you are now certified as a Red Hat Certified Engineer!''
Attachment:
pgpL8lFr1I1_U.pgp
Description: PGP signature