Hi folks, It's with some regret that I have to confirm that m68k is not going to be a release architecture for etch. I don't expect that this comes as any great surprise; m68k's shortfalls with regards to the release standards have been documented for some time, and in spite of what I know has been a diligent effort on the part of all the m68k porters, this status has not improved over the past months. Indeed, the status regarding archive coverage has remained constant, at a level below the other architectures and too low for us to consider releasing.
From <http://release.debian.org/etch_arch_qualify.html>, here's a brief recap of where m68k fell short: archive coverage: 92% This indicates that m68k is generally not able to keep up with necessary porting work for new software entering the archive, with 8% of all packages not available. http://buildd.debian.org/stats/graph-quarter-big.png up-to-date: 95% This indicates that, due either to regressions in support for the architecture or inability of the autobuilder network to keep up, 5% of the packages previously built for m68k are not up to date. This adds up to 228 source packages in unstable for which m68k would currently prevent updates in testing (if m68k were not being ignored), 562 packages in testing that are out-of-date on m68k, and 221 packages in testing that are uninstallable on m68k. http://buildd.debian.org/stats/graph2-quarter-big.png buildds: 19 There are 19 buildds actively uploading packages for m68k (Aug 20 to present). This indicates that individual buildds are roughly an order of magnitude slower than those for other architectures, which makes m68k a limiting factor for time-critical builds such as security updates. So with three months remaining until the scheduled release of etch, the release team does not believe it's possible for m68k to close the gap on these issues. As a result, the bts is already ignoring m68k in calculating a bug's applicability for the testing distribution, at the release team's request. We have also asked about removing m68k from testing since it is not currently a release candidate; Anthony Towns has indicated his preference to defer this until another solution can be implemented for m68k's needs. This raises the question again of what such a structure should look like; I think it would be a good idea for us to begin to tackle this question, so that the m68k team might, e.g., be able to do their own partial release for etch similar to what amd64 did for sarge. Or, perhaps this is a good time to focus on ColdFire support, so that m68k can come back with as strong a port as possible for etch+1? Please let the release team know how we can be of assistance to you in setting and meeting goals for an m68k release, be it for a separate etch release or for a re-integrated etch+1 release. -- 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/
signature.asc
Description: Digital signature
