Re: Debian needs more buildds. It has offers. They aren't being accepted.
Anthony Towns <aj@azure.humbug.org.au> writes:
> On Sat, Feb 14, 2004 at 09:56:50AM +0100, Eduard Bloch wrote:
> > #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:
> > > > We want kde 3.2.0 in sid so it is (tried to be) autobuild.
> > > No, we don't want KDE 3.2.0 until we *know* it can be autobuilt. Uploading
> > > it to experimental and asking developers to build it on various
> > > architectures tells us that to a good approximation, and allows us to keep
> > > working on KDE 3.1.5 in the meantime.
> > So? Wasn't you favorite Testing branch intended to be a place for
> > "working versions"?
>
> Yes it is, but that doesn't help here because KDE and Qt don't meet the
> appropriate definition of working.
>
> And as it turns out, keeping testing working requires that we not upload
> just anything into unstable -- in particular it causes significant
> problems if we upload things that we're not able to fix in a timely
> manner. That's why uploads of a major new versions, particularly of major
> packages with lots of dependants, or complicated interdependencies should
> be made to experimental first wherever possible.
>
> > Since Testing seems to mutate to another outdated,
> > deadlocked package set, I understand the wish to make Sid the distro for
> > everydays work - but it is not how the things should be.
>
> The goal has always been to have testing mostly working, and mostly up
> to date with unstable. That's not possible if the versions in unstable
> remain in a non-working state for a long time, and apparently it's more
> common for that to happen than I or others originally expected. To deal
> with that, we need somewhere to upload packages that are likely to be
> broken for an extended period. That place is experimental, and KDE 3.2
> is exactly that sort of package.
Ah, got you now.
> > 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.
>
> In the long term, there's no reason at all. In the short term, it's
> too difficult and there are complications. If you want to set up a
> buildd for experimental on your own bat, you're entirely welcome to,
> and indeed encouraged.
>
> Cheers,
> aj
MfG
Goswin
Reply to: