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 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. 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 solutions. > 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.) Cheers, FJP
Attachment:
pgpqBrkINbKkk.pgp
Description: PGP signature