Op za 14-02-2004, om 09:56 schreef Eduard Bloch:
> #include <hallo.h>
> * Anthony Towns [Sat, Feb 14 2004, 05:41:51PM]:
> > On Fri, Feb 13, 2004 at 04:10:29PM +0100, Goswin von Brederlow wrote:
> > > Having it
> > > in experimental for the one arch the maintainer has will not solve the
> > > RC bugs that might show up on the other archs.
> >
> > Indeed, that's why you don't just have it in experimental for one arch.
>
> And is that the reason for making autobuild-trials on other arches a
> real pain for maintainers with packages in experimental? I see no good
> reason for not running autobuilders on experimental.
I see two of them:
* Resource problems. The autobuilder infrastructure has been built
to support unstable, stable security updates, and, occasionally,
testing-proposed-updates (doesn't happen too often, but it's
there and it'll need to be built). Adding experimental to that
would require extra systems for some ports (I'm not sure, e.g.,
m68k has the surplus cpu power required currently).
* Doing experimental autobuilds would require a lot more from the
autobuilder maintainer; after all, the idea is that if one
expects a package to break, it's being put in experimental. This
means that an experimental chroot is much more likely to break,
so would put an extra burden on the autobuilder maintainer.
Me, I wouldn't have any problem adding an experimental chroot and
starting builds of packages in experimental, as long as it's clear that
unstable is our first priority, and that there is no guarantee that a
package in experimental is ever built by a buildd.
--
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
Most people have two reasons for doing anything -- a good reason, and
the real reason
Attachment:
signature.asc
Description: Dit berichtdeel is digitaal ondertekend