Hi, On Sun, 17 Sep 2006, Steve Langasek wrote:
> buildds: 19 > There are 19 buildds actively uploading packages for m68k (Aug 20 to > present). This indicates that individual buildds are roughly an order of > magnitude slower than those for other architectures, which makes m68k a > limiting factor for time-critical builds such as security updates. > > So with three months remaining until the scheduled release of etch, the > release team does not believe it's possible for m68k to close the gap on > these issues. This will always be a killer argument against supporting slower ports. :-( > As a result, the bts is already ignoring m68k in calculating a bug's > applicability for the testing distribution, at the release team's request. As someone who has recently looked at and fixed many problems, I must say the release team has done m68k no service by doing this and actually sabotaged m68k in its ability to catch up again. Fixes for problems are too often simply stuck in the BTS now, because in many cases maintainer simply don't care about m68k support. I often have to bug people to get them to release a fixed package. It's one thing to expect from m68k not to hold up other ports, but it's a different thing to take from m68k the means to catch up again. > We have also asked about removing m68k from testing since it is not > currently a release candidate; Anthony Towns has indicated his preference > to defer this until another solution can be implemented for m68k's needs. > This raises the question again of what such a structure should look like; I > think it would be a good idea for us to begin to tackle this question, so > that the m68k team might, e.g., be able to do their own partial release for > etch similar to what amd64 did for sarge. So the situation is now that m68k gets kicked out without no alternative in place? Once the current building frenzy calms down, the situation shouldn't look too bad and if bugs for which fixes exists in the BTS where actually fixed, m68k could be released with just a few packages less. Not releasing m68k could have far worse consequences and should be absolutely the last resort, e.g. it makes it difficult to upgrade between stable releases, which might become a real issue, as m68k is likely to need an ABI change for TLS support. What are the alternatives for m68k _now_? To me it looks like the release team is expecting a miracle. It's a fact that m68k is a slow port and as long as the release team is insisting on "fixing" this, m68k is doomed. :-( bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
