On Mon, Mar 21, 2005 at 09:51:25PM +0100, Falk Hueffner wrote: > Matthew Garrett <mjg59@srcf.ucam.org> 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. Aside from concerns about the availability and cost of replacement hardware, it's likely that new systems will continue to be sold for some time after the chip manufacturers stop designing new (faster, better) chips, so such systems are not going to be keeping up with the increase in CPU demands of compiling the archive. 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? 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? > > * the value of N above must not be > 2 > > This effectively sets an upper limit on the length of time a single > > package may take to build, which helps ensure that doing things like > > security fixes for Openoffice doesn't become a problem. > If the point is to set an upper limit on the length of time a single > package may take to build, why not take that directly as a criterion? > It is even more objective. It might also encourage people to split > unreasonably large packages. Wouldn't this also be an arbitrary penalty on slower architectures, though? The porters don't control the size of the largest packages in the archive; and package sizes do continue to go up, just like everything else. 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. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature