On 19.05.2012 23:59, Samuel Thibault wrote: > Hello, > > Cyril Brulebois, le Sat 19 May 2012 19:41:56 +0200, a écrit : >> (Ewww, long lines) > > Oops, sorry, I forgot to reindent after import from the pad. > >> Samuel Thibault <sthibault@debian.org> (19/05/2012): >>> - We of course aim at tech preview for wheezy only, not a full >>> release. Our goal is to establish a testing distribution for wheezy >>> which does not block others ports (i.e. so-called fuckedarch), and get >>> a full testing for wheezy+1. >> >> Starting a testing distribution for an arch less than a month before a >> freeze doesn't smell too good to me. > > Well, doing it before might have meant more work for everybody. > >>> - It is fine to us to see problematic binary builds (e.g. blocking >>> testing migrations eventually) be removed, even if they have a couple >>> of rev-deps. >> >> Including big packages like say webkit or kde4libs or anything similar? > > I guess we have to say yes. > >>> Concerning the archive coverage, the 76% figure should be accurate for >>> the current state. The freeze period should allow us to continue >>> increasing it more easily (no new upstream releases). If you look at >>> the current buildd figures, we are rather at 75%, this is due to >>> current transitions, the gcc-4.7 FTBFSes, and webkit FTBFS (about to >>> be fixed). >> >> I wouldn't be very happy to see unblock requests just to get hurd-i386 >> fixes in testing, if that's what you're suggesting. > > Even when they are just e.g. #include or configure.ac cases? > >>> Concerning installability, it currently can not really be measured >>> because the latest upstream webkit release is once more broken for >>> some trivial reasons, #669059, making a big part of gnome >>> uninstallable. The haskell transition doesn't help either :) >> >> Exactly the kind of situation that led my asking about removals of >> problematic binaries above. > > Well, the problem is that as long as hurd-i386 port is not released in > any sort, people care less about it. A patch was submitted to the webkit > package quite soon actually, but it wasn't applied just because it was > out of the maintainer's radar, and he didn't notice it, while the exact > same patch, submitted to fix kfreebsd, was quickly applied, since its > severity was "serious". Once an architectures is a release architecture and a package is in testing, it becomes a burden for the maintainer. We have to do all sorts of workarounds to make packages build on all available architectures. This means includes disabling test suites on problematic archs and, like kfreebsd* or e.g. ia64 (webkit, seed, ...), or just compiling dummy stubs. All we basically care for is that the package builds, not that it actually is working. I've experienced this a couple of times during the last months/years. This is a bad trend, imho I'd rather see us enable test-suites and make the failures fatal. But this would mean we suddenly get a lot of FTBFS and we are no longer able to get packages into testing. This is very unfortunate. I'd be *very* unhappy if hurd became an architecture that blocks packages from migrating to testing. We already have enough problems with kfreebsd. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature