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

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

Thomas Bushnell BSG wrote:
> > - network bandwith (witness the discussion on mirror efficiency),
> Mirrors don't have to (and don't need to) copy all the archs.  They
> can support whichever ones they want.  Nor could this possibly slow
> release.
> > - mirrror capacity (witness the sad state of amd64),
> But dropping an arch can't improve the capacity of a mirror which
> doesn't carry it, and they can always simply not carry it if they want
> to.

That's predicated on the assumption that mirrors can easily or feasibly
do such a partial mirror. The small number of mirrors that have, the
smaller number of important mirrors (push-primary, top-level country
code mirrors, etc) that have, and the fact that the ftp-masters have
this upcoming SCC project to make it easier, belies that.

> > - security response time (more builds to do)
> Which DSAs came out later than they should have because of this
> supposed delay?  Nor could this possibly slow release.

DSAs are occasionally delayed waiting on builds. The priveliged nature
of much of the information surrounding DSAs makes it impossible for me
to give a list, but I've seen it happen repeatedly. The most glaring
example in recent memory is the 6 or so months it took for us to get
updated kernels in stable for last spring's set of very bad kernel
security holes.

Security bugs which are currently not fixed in testing, and which either
would be fixed there or would not be a concern if it wasn't for the need
to support all architectures include:

 bidwatcher 1.3.17-1 needed, have 1.3.16-1 for DSA-687-1
 bind 1:8.4.6-1 needed, have 1:8.4.4-1 for CAN-2005-0033 
 emacs21 21.3+1-9 needed, have 21.3+1-8 for CAN-2005-0100, DSA-685-1
 kdeedu 4:3.3.2-2 needed, have 4:3.3.1-3 for CAN-2005-0011
 kdelibs 4:3.3.2-2 needed, have 4:3.3.2-1 for CAN-2005-0365 
 kernel-image-2.4.27-alpha (unfixed; bug #280492) for CAN-2003-0465
 kernel-image-2.4.27-sparc 2.4.27-2 needed, have 2.4.27-1 for CAN-2004-1056, CAN-2004-1235
 kernel-patch-powerpc-2.4.27 (unfixed) for CAN-2004-1056, CAN-2004-1235 
 xemacs21 21.4.16-2 needed, have 21.4.16-1 for CAN-2005-0100, DSA-671-1
 xview 3.2p1.4-19 needed, have 3.2p1.4-16 for DSA-672-1

> > - scarce resource such as release managers, ftp admins, ...
> > if we have to look after arches that are *not really used*.
> All of whom have said that this doesn't actually slow them at all.

To the contrary, I've publically said before that the need to support
all our architectures (in d-i) has prevented me from doing other work
that I could have done to advance the release.

The release of d-i RC3 has been delayed for several months now because
that's how long it takes to update the debian kernel packages for all
arches. I've spent at least one man-week of full-time work during that
time period in tracking what work still needed to be done and working
with the debian-kernel team, ftp-masters, d-i team, and others to get
the updated kernels in place.

I've spent approximatly one man-month of time in the past year on
setting up and running an automated test lab for the debian-installer on
6 or 7 architectures. For some lesser-used architectures, the install
tests from this lab are the only way we have to know if the installer is
generally working on a day-to-day basis, since we get only rare
installation reports from users of those arches.

The above is just the tip of the iceberg WRT architecture specific d-i
work that I have to do. If I hadn't needed to work on that stuff due to
the requirement that d-i release on all arches, then I would have
certianly been able to devote more time to other things, including
testing security work, other release-critical areas of d-i, and so on.

I'm not particularly advocating dropping any architectures at this
point, but I do think that people who shrug off the impact of our
supporting so many architectures are not arguing from a very strong

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: