[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: summarizing arch status

On Sun, Jun 04, 2006 at 11:24:46AM +0200, Andreas Barth wrote:

> AFAICS, we have the following architectures we released sarge with and
> which are currently no release candidates for etch:
> - m68k:
>   - some subarches require 2.2 and/or 2.4 kernels - I don't think we
>     will support that (but we could also just drop these
>     subarchitectures, like we did for 80386 with sarge).

I don't think we should be keeping 2.2 around, period.  If an architecture
needs 2.2 in order to release, it shouldn't be a release arch.

The same feeling applies, to a lesser degree, with 2.4.  It would be one
thing if we were already going to be keeping 2.4 around for other users, or
if the m68k porters put us over critical mass for being able to support 2.4
for the good of all; but so far, everyone else I've talked to has concluded
that their efforts were better spent porting drivers and whatnot to 2.6 than
to try to support 2.4.

So the big question is whether m68k can sustain a port without these
kernels, and Wouter seems to have confirmed that yes it can.

>   - traditionally weak with keeping up, but currently in good shape

I don't agree that http://buildd.debian.org/stats/graph2-quarter-big.png
shows it "in good shape".  We can expect the build load to get worse, not
better, with a push for the release...

> - s390:
>   - 3.5 developers or so only
>   - installer support weak - 2.4 only currently, but this is not enough
>     if we drop the 2.4 kernels

Hrm, is this still the case?  I think the 2.4-only-ness of it was lost on
me; I knew of some issues with dasd support in the etch d-i, is that the
same thing or not?

> - sparc:
>   - kernel support? we had spontanous reboots there.

There is a kernel in place on the buildds that's proving stable, but it's
*not* the kernel from sarge etch; it's newer even than the one currently in
sid.  AIUI, there are concerns about having to run the buildds in such a
configuration in the long term.

The ideal fix here is to get the necessary kernel changes backported into
the Debian 2.6.16 kernel package.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: