Anthony Towns <[email protected]> writes: > On Fri, Oct 27, 2006 at 12:47:19PM +0200, Roman Zippel wrote: >> On Fri, 27 Oct 2006, Anthony Towns wrote: >> > Personally, I think m68k would be better served by having a testing-m68k >> > and taking occassional snapshots which serve as the supported stable-m68k >> > release, rather than worrying about something equivalent to etch itself. >> Why should we do this? As it looks right now, we are in not much different >> shape than most other ports [...] > > Roman, please stop beating that horse. > >> The only problem right now is our backlog and we'll hopefully >> see soon how quickly it can be reduced via distcc. > > FWIW, that would be a lot more convincing if it had happened a year ago > when it was last suggested... > > http://lists.debian.org/debian-devel-announce/2005/08/msg00009.html > > Cheers, > aj
That same mail also lists the qualifying criteria with 2 important points that m68k fails: 1) must be able to keep up with unstable with 2 buildd machines, and must have one redundant buildd machine Wasn't that point waved for m68k as it gets granfathered in? If that condition is insisted upon then getting a buildd with distcc+cross-gcc up would be much more pressing. So far there was no big need for it so development and testing has been slow and purely on a spare time and for fun basis. 2) must have successfully compiled 98% of the archive's source (excluding arch-specific packages) The ONLY port that has had this over a 3 month period is i386. ALL other ports fail this criteria. And even looking at single days some ports just barely get above 98%. http://buildd.debian.org/stats/graph-quarter-big.png I think this criterian needs serious reconsidering and/or serious cleanup of the stats for each arch. Currently m68k has over 1% of the archive's source in Not-For-Us pending inclusion in packages-arch-specific. That alone brings it 10% closer to the 98% mark already. Redefining what constitutes arch-specific to something more based on 'usable' than 'can potentially run' could also drastically change the stats. Sid only packages should also be removed from the stats as they have no impackt on testing. Overall I have to say that this criteria is stupid. Having a package not available on some arch does not create any extra work for the release. Leaving out sources completly should be no problem at all. Packages that are out of date are the problem as they hold things up. The usability of a port also doesn't suffer. I bet you could selectively remove 30% of all sources from non mainstream ports and wouldn't even get a complaint. Instead the % of the archives source that is up-to-date should be used and a wider range. Even there most archs are betwen 97% and 99% and nobody wants to kick them out. And the port should be given the option of having a list of testing-ignore-packages. A package in testing-ignore-packages is not arch-specific but considered probably useless by the port. Such a package does not block a testing transition for that arch and gets removed from testing for that arch if it the arch can't keep it up-to-date. If the port manages to build it fine, if not then fine too. No penalty should be given for useless stuff. Packages could also be black listed for requiring too many resources to build for the security team to maintain them in a timely manner. I guess the security team would have full power over that. Something like mozilla might get excluded from stable m68k for taking too long to build. Since this would need DAK support I suggest using Not-For-Us and removing the useless packages from etch and sid for now. After the release the feature can be implemented and the packages added back in. In summary there is a lot more Debian can do at little cost to get slower ports like m68k and arm within acceptable limits instead of just leaving them out in the cold. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
