(Ewww, long lines) Please keep in mind I'm quite new in the release team, so I'll just reply on some points that stroke me. I don't speak for the team as a whole.
Samuel Thibault <sthiba...@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. > - 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? > 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. We already have plenty of work to do without having to deal with that kind of requests. > 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. > Concerning hardware support, Linux 2.6.32 network drivers are now > included and will be used by default in the coming days. That provides > a fairly good coverage of not too-new hardware. We are working on > integrating the linux AHCI driver to support SATA HDDs. Concerning > X.org, drivers which do not require drm should be working. At worse, > the vesa driver should work. There is no USB support, no sound > support. On a (very) personal note, the apparent lack of HW support is making it look very bad… > Concerning the debian-ports packages, it is probably good to provide > more details. The status is tracked on our wiki page: > http://wiki.debian.org/Debian_GNU/Hurd From there, basic stuff like working local sockets and select() might be missing… “Get Xorg + gnome/kde/xfce (xfce should work, kde is missing working dbus (due to local socket auth and bugs in select() cornercases)) + some webbrowser working (iceweasel 9 works, though not https).” Bottom line for me: - way too late in the release cycle to consider adding hurd-i386 to testing (even as a bad arch). - not happy with unblocking packages just to get hurd-i386 fixes in, already plenty of bugs to deal with on real architectures. Mraw, KiBi.
signature.asc
Description: Digital signature
