Re: m68k release future
Anthony Towns <aj@azure.humbug.org.au> 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
Reply to: