Re: m68k not a release arch for etch; status in testing, future plans?
On Wed, Oct 18, 2006 at 05:12:40PM +0200, Roman Zippel wrote:
> > I can understand you are disappointed, but please try to be constructive
> > and help create the best support for m68k possible given the decision
> > that was made and work to get m68k to be a fully supported arch again for
> > etch+1.
> If the decision has already been made, does my attitude really matter?
> I'm only trying to be realistic and based on the current situation, m68k
> is unlikely to ever get its release status back, so I'm seriously asking
> myself why I should even bother.
Well, no, you also seem to be asking everyone on two mailing lists why you
The release team can't answer this for you. If the porters believe m68k
won't be releasable in the future, they're probably right. If they believe
it will be and are trying to meet the release goals, there's at least a
chance. But you need to find your own motivation for wanting the port to
release (in whichever form), because I'm not going to try to talk anyone
into keeping the m68k port alive; it's not a port that I personally have any
use for, and its speed has been a problem for the release team and a source
of discontent for package maintainers for years before the arch criteria
If it's important enough to *the m68k porters* to do the work for m68k to
meet the release requirements (or to make it releasable on its own in some
other fashion), then I'm certainly happy to do the work necessary for m68k
to be treated on an equal footing with the other architectures. What I'm
not willing to do is to do a massively disproportionate amount of work to
accomodate an architecture which isn't able to keep up with the pace of
Insisting that m68k could never meet the architecture release requirements
doesn't make me think we're being unfair to m68k, it reinforces my belief
that cutting m68k from the full release was the correct decision. The
arch criteria weren't just pulled out of a hat, they were written to address
specific ways in which an architecture can pull down the release process or
cause support problems post-release.
> We had indeed problems during development, but isn't the purpose of a
> development stage to find and fix such issues? I really don't understand
> that now at the end of the development stage there is absolutely no
> intention to even look at the current situation and figure out what would
> be needed for proper m68k release. Instead there is only hiding behind
> release criteria and anonymous decisions.
I don't believe it's realistic for a port to get back up to speed for
release during a freeze if it hasn't been keeping up or hasn't caught up
before that point. There will be other bugs found that will need to be
fixed in the process of trying to build those packages that were held up by
the previous toolchain issues, and I would expect a fair number of those
newly-discovered bugs to require freeze-exceptions to address. Which means
the freeze time would be eaten up trying to get m68k in shape for release,
instead of on fixing up the "few" remaining RC bugs as intended.
And the condition of m68k with respect to the release criteria has declined
since the decision was made, with the arch further lagging by a full 5% of
> > > You are practically declaring that Debian is now a Desktop only
> > > distribution which will only support GHz machines.
> > The fact that m68k is the only arch that was eventually not considered to
> > be release quality makes this untrue.
> Actuallly arm is considered as well (at least it was threatened in one of
> the announcements) and strictly speaking arm doesn't meet the release
> criteria either...
Would you feel better about m68k's status if you had arm for company?
Strictly enforcing the release criteria for arm isn't going to get m68k any
closer to being reincluded as an arch candidate.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.