On Tue, Dec 31, 2013 at 10:34:49AM +0100, Niels Thykier wrote: > > You rightly point out that keeping the architectures in testing has a > > cost, because the architectures will block testing migration. But are > > the kfreebsd archs actually causing testing blockages, in practice? If > > there are such blockages, can you give us more information about how > > this has been the case? > I have been seeing quite a few packages FTBFS on kFreeBSD being stuck in > sid with fixes for RC bugs in testing. Of course, this problem is by no > means exclusive to kFreeBSD - other architectures (sometimes, even i386 > or amd64) also "features" on that list of blockers. > The only purely factual data I got currently, is the little snippet at > the bottom of Britney's log. I am not sure how reliable it is, so I'll > refrain from using it as an argument. But I think we (i.e. the > distribution) could do with an accurate data source on this topic! I agree, it would be nice to have solid data on this. > On a related note, I suspect a good part of this problem would go away > if we had an automated tool to deal with the case where a (sid-only) > FTBFS is ignored. It happens sometimes that the maintainer does nothing > (or, maybe, does not realise the package FTBFS on arch X) and neither > the porters nor the buildd admins filed a bug for it. > Then it is not until the package gets in way of a transition (or some > other RC bug fix), that the package gets its RC bug. I have seen a > package stuck in sid for at least 90 days and still no RC bug - the > "only" thing wrong was an "Out of date binaries" on some architecture > (don't remember which package nor which architecture). Historically, it was considered the porters' responsibilities to deal with these packages that are failing to build in unstable. Indeed, this was even expressed in the release criteria at one time: a port is not releasable unless it's x% up-to-date, because not being up-to-date for any reason (buildds offline, porters not signing builds timely, toolchain or individual packages regressing on one particular architecture) causes problems for testing migration. Maybe it's time to draw a new line on https://buildd.debian.org/stats/graph2-week-big.png, corresponding to what's actually needed for a port to be releasable? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature