Re: pilot-link in Sid and Sarge: Much bigger question
On Mon, 28 Apr 2003, [iso-8859-1] Björn Stenberg wrote:
> After all, it's sarge that's the release candidate right? Not sid. So why is
> sid allowed to dictate dependencies that sarge must conform to?
I think it's because sid is meant to be sarge+2 weeks, if all goes according
to plan...
> Kill holy cow #1: Binary compatibility. Testing is a separate release,
> treat it as such. Branch it off and set up it's own buildd server. Build
> packages in testing with tools and libraries from testing. Don't use
> binary packages from unstable, recompile them. Make sarge, not sid, the
> reference environment for sarge.
As a practical point, I don't think we'd have the buildd's to do this.
Unless someone has unearthed a dozen m68k machines recently, we've got at
least one architecture running behind already. Rebuilding for testing, too,
would require identifying which package in the package pools was the sarge
version and which was the sid version, with all the concomtant confusion
which would result from that.
If we could get the hardware to do it, and somehow work out the archive
issues, rebuilding packages for testing would help make packages progress
into testing quicker, for more exposure.
That reminds me of a partially-related point - what happens with my
packages, built on a woody+bits system, when I upload the binaries for
i386? Does the i386 version of my package have all sorts of woody+bits
dependencies, while all other arches have sid-clean dependencies? Hmm, a
dirty hack for getting into sarge...
> Kill holy cow #2: All-port concurrency in testing. Make a testing-i386
> release, where admittance rule #2 is replaced with "It must be compiled
> and up to date on i386." Statistics posted to this list earlier show that
> i386 has the lowest number of build problems of all ports. And I think
> it's safe to say that it has the highest number of users. Combine the two,
> and you get stuff tested. A lot.
This holy cow was beget from the idea that testing should always be a
release candidate. Considering the lengthy freezes we tend to live in
before a release, I don't think that idea was ever valid.
I'd like to propose another level of testingness, but I won't because it was
enough pain putting testing in. If the information can/is being tracked,
any package which doesn't build on all arches at the time of the freeze just
gets dumped. If you can't/won't make your package work in Debian[1], it
won't be.
> > people prefer bitching and complaining about testing being late and
> > stable being old, rather than helping fixing bugs.
>
> Perhaps one reason is that fixing enough bugs to get stuff into testing is
> currently a whack-a-mole job? With so many dependencies changing all the time,
> there is no solid ground. Once you've fixed the showstoppers in package A,
> package B uploads something which breaks, you fix that, then C uploads, you
> fix that, then a new version of A pops up again...
I don't think your proposals will really fix that, since in my experience
that new version of A probably requires all sorts of new crap from B
anyway...
--
-----------------------------------------------------------------------
#include <disclaimer.h>
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16
Reply to: