[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 Wed, Oct 18, 2006 at 10:08:35AM +0200, Frans Pop wrote:
> On Wednesday 18 October 2006 03:43, Roman Zippel wrote:

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

True, but the whole story is quite discouraging... 

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

Migrations are an issue, whereas I think security can delayed for m68k by a
few days, so that security fixes for other archs don't need to be delayed.
This happens already from time to time. 

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

Other DDs were already wondering why/how the arm port made it in... so, this
makes the drop of m68k just a case of bad luck with gcc-4.0 and toolchain.
Making gcc-4.0 the default compiler was really not a good choice for
m68k. 

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

I think alternative solutions should have been provided by the Vancouver
proposal already. 

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

Not? 
Especially Roman has put great effort into fixing bugs and making the
toolchain stable again during the last weeks. 

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

Hmmm, was it around that time when Stephen went on holiday? It seems he's
back, so that might change soon then... ;)

-- 
Ciao...                //        Fon: 0381-2744150 
      Ingo           \X/         SIP: 2744150@sipgate.de

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc



Reply to: