On Tue, Mar 22, 2005 at 09:36:46AM +0100, Falk Hueffner wrote: > > On Mon, Mar 21, 2005 at 09:51:25PM +0100, Falk Hueffner wrote: > >> Matthew Garrett <[EMAIL PROTECTED]> writes:
> >> > * the release architecture must be publicly available to buy new > >> > Avoids a situation where Debian is keeping an architecture alive. > >> I don't understand this. What is the problem with Debian is keeping an > >> architecture alive? What problem are you trying to solve here? > > Given that there are architectures that have been end-of-lifed (but > > *are* still available for purchase new) that we've had problems > > keeping our autobuilders running for, I think it's a fair guess that > > hardware that truly is no longer available for purchase is going to > > be costly for the project to continue to support for a stable > > release. > This is too vague for me. <sigh> Does the release team now have to do price shopping on replacement parts for buildds before it can say that it doesn't want to support dying platforms? > > Aside from concerns about the availability and cost of replacement > > hardware, > Has this really been a problem for Debian? One of the delays affecting getting lully.d.o back on line, AIUI, was a dead power supply that was non-trivial to replace. This is a case of scarce hardware impacting a port even *before* it has ceased to become available for sale. > > This adds up to a lot of effort for a dead-end architecture. Do you > > believe that such ports are going to command enough interest to be > > able to keep up with Debian's stable support requirements for more > > than 2 1/2 years (18mo. release cycle + 1 year support for > > oldstable) after being discontinued as a product? > Given that you'll probably not be able to buy an i386 box in a few > years anymore, I'd say "yes". But I see little point in trying to > guess here. Ports that cannot keep up should be filtered by the other > criterions. Really? You can still buy 486 chips new for use in embedded applications (or so we've been told in previous threads about C++ ABI breakage); but you think that x86 as a class will cease to become available in a matter of a few years? > > Furthermore, do you believe that the limited resources of DSA (which > > will *always* be limited, no matter how big you say you want the > > team to be, because there's *always* more to do than there are > > people to do it) should be spent keeping stable security buildds for > > such architectures running, instead of on tasks that are useful to > > users of living architectures? > This is again pretty vague. You basically say that we need to drop > architectures, and we should drop those that are "not living". > Firstly, this particular criterion is not effective at dropping > architectures: currently, all of our architectures can be bought new. > Secondly, it doesn't seem like a good criterion for determining > "livingness": arm, mips, and m68k are basically immune to this for the > next 10 years or so, since they are used in embedded systems and can > be produced very cheaply. I already mentioned i386 as a contrast. You didn't answer the question I asked. Do you believe that DSA should be spending its limited resources keeping hardware running for dead architectures? And given that none of our current architectures are "dead", why is it important to argue this point? > > Build time for a single package is also only one of the concerns; > > the other big one being that it's much more likely to get security > > wrong for one out of ten buildds, rather than for one out of three. > What do you mean by "getting security wrong"? Can you give an example? > Is there evidence that this is a problem for the architectures that > currently have many buildds? Is reason dead? Do I really have to have proof of past buildd compromises to argue that it's betting against the odds to not consider sheer number of machines a security concern? Do you really think that if there *was* proof of past buildd compromises in Debian, anyone would give a damn about whether we have "security" support for etch? -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
