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