[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

m68k not a release arch for etch; status in testing, future plans?



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.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature


Reply to: