Hi folks, So last month Andreas Barth wrote to say that the release team was considering ignoring m68k for testing propagation, because it has not been keeping up with the archive, and as a result is blocking fixes from reaching testing unless they are manually overridden. At the time, here is what the breakdown looked like of missing builds holding packages out of testing:
460 m68k 227 arm 174 mips 148 hppa 132 s390 114 sparc Here is what it looks like today: m68k: 397 arm: 285 sparc: 214 mips: 153 hppa: 125 alpha: 93 While you can see that this is an improvement for m68k in absolute numbers, and also that a couple of other architectures are now looking worse than they did in September, this is unfortunately not the improvement we need to be seeing for the port. Moreover, these numbers only reflect out-of-date packages, they don't show new packages that are not yet built on m68k -- at least some of which are a factor because they are build-dependencies of other packages which *are* out of date. For another metric of how well architectures are (not) keeping up with unstable, please see: <http://buildd.debian.org/stats/graph-week-big.png>. As a result, this evening I've asked Anthony Towns to configure britney to ignore m68k when considering packages for testing so that it no longer holds up fixes for the other architectures. As Andreas wrote before, this does not mean we are ruling out the possibility of releasing m68k with etch. It *is* an indication of how much work needs to go into m68k in order for it to be in a releasable state. I realize that part of the reason for the current state of affairs on m68k is the large buildd backlog (326 packages in w-b state Needs-Build), and that there are limits to how quickly this backlog can be cleared. There are also other areas that need attention, though, which don't require you to be a buildd maintainer to help with (though obviously knowlege of m68k, and the ability to test, are important). From <http://buildd.debian.org/~jeroen/status/architecture.php?a=m68k>, there are 125 packages in state Failed, 138 in state Dep-Wait, and 45 that are Maybe-Failed; as well as 27 packages in state Not-For-Us. These are all packages which count against m68k when attempting to judge the port's releasability. Please, if you want m68k to release with etch, work on turning these into RC bug reports for packages, porter NMUs, re-queued packages in the case of transient failures, or entries for Packages-arch-specific (http://buildd.debian.org/quinn-diff/Packages-arch-specific) in the case of packages that are not candidates for inclusion on m68k. In addition to getting the count of m68k blockers in unstable down to a more moderate level, because m68k is now being ignored we will need to pay special attention to <http://ftp-master.debian.org/testing/testing_outdate.txt> and <http://ftp-master.debian.org/testing/testing_probs.html>[1], which show packages that have allowed to become out-of-date or uninstallable on m68k. As m68k begins to catch up again these numbers should go down on their own, but there may be some stragglers which don't find their way into testing once built, for one reason or another. Your help in controlling this will be appreciated. The release team will continue to monitor the progress of the m68k port. If you have any questions about where to go from here, please ask us. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ [1] this page also lists all arch: all packages that are uninstallable on any arch, so one will need to filter the list looking for packages that are uninstallable *only* on m68k...
signature.asc
Description: Digital signature
