Re: Results of the meeting in Helsinki about the Vancouver proposal

[Andreas Barth <aba@not.so.argh.org>]

* Olaf van der Spek (olafvdspek@gmail.com) [050822 17:01]:
> On 8/22/05, Andreas Barth <aba@not.so.argh.org> wrote:
> > * Olaf van der Spek (olafvdspek@gmail.com) [050822 12:35]:
> > > On 8/22/05, Steve Langasek <vorlon@debian.org> wrote:
> > > > In particular, we invariably run into arch-specific problems every time
> > > > a new version of a toolchain package is uploaded to unstable.  Some may
> > > > remember that the new glibc/gcc blocked non-toolchain progress for
> > > > months during the beginning of the sarge release cycle, and that the
> > > > aftermath took months more to be sorted out.  So far, etch threatens to
> > > > be more of the same; in the past month we've had:
> > 
> > > I've been wondering, why isn't the new toolchain tested and the
> > > resulting errors fixed before it's uploaded to unstable or made the
> > > default?
> > 
> > Because apparently nobody does. To really find out (some of) the
> > toolchain bugs, you need to compile the whole archive with the new
> > toolchain. And, BTW, the new toolchain was available in experimental for
> > ages. Gcc 4.0 was also uploaded quite some time to unstable before it
> > was made the default.

> I understand most maintainers don't try the new toolchain themselves,
> but wouldn't it be possible for someone else to build the entire
> archive (or parts of it by multiple people) and (automatically) report
> bugs?

Building is possible and has happened. About 500 of such bugs were still
not resolved when gcc-4.0 was made the standard. But some obscure
usage-breakage won't be noticed by that, unless the package has a decent
self-test.

So, in sum: yes, we try to do that as much as possible.



Cheers,
Andi