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 position. -- see shy jo
Attachment:
signature.asc
Description: Digital signature