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

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

On Wednesday 18 October 2006 03:43, Roman Zippel wrote:
> > No, releasing with etch is out of the question -- m68k doesn't meet
> > the release criteria.
> Well, this means the release criteria have been designed in a way that
> m68k never could have met them anyway, m68k was practically fucked
> either way from the very beginning. This whole process is a charade and
> was pretty much designed to kick out slower ports. :-(
> > The question is what to do _instead_.
> The point is that m68k gets kicked out _before_ any alternative has
> been implemented. _Any_ m68k work has been in vain from the very
> beginning and the question is now only how some of it can be
> salvaged...

Come on. This attitude is not going to lead anywhere.

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 
It is a fact that some arches, but especially m68k and m68k most 
constantly and structurally, have caused loads of extra work for RMs, FTP 
masters, security team, etc, for a large part because it is slow when 
compared with others. This has delayed important migrations, security 
updates, etc.

I think most people, including RMs, would be happy to welcome m68k back if 
these issues could be addressed and have deep respect for the m68k 
porters. In my experience m68k is one of the most active ports withing 
Debian, but that does not change the facts.

> 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.

Please try to be more constructive as your current attitude is only going 
to make people less inclined to work with you to create alternative 

> The only problem  right now is that m68k is slow and that can't be fixed
> magically,

Which was not the case when the decision needed to be made and was made. 
IMO the RMs delayed it as long as possible to give m68k a chance.
Maybe, in retrospect, the should have made the decision earlier so there 
would have been more time to work on an alternative solution?

> unfortunately I don't see any serious effort to accommodate for these
> needs. 

And I have not seen any serious work or proposals from m68k porters in 
this direction either. ATM everybody is busy with the release. As always, 
the initiative has to come from those most involved: the porters.

For what it's worth, the installer will keep supporting m68k. (Although it 
would be good if we could have an updated daily build; the last one was 
Oct 10.)


Attachment: pgphPeRkqYpit.pgp
Description: PGP signature

Reply to: