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: [EMAIL PROTECTED]
gpg pubkey: http://www.juergensmann.de/ij/public_key.asc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
