Re: How to define a release architecture
Steve Langasek <vorlon@debian.org> writes:
> 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.
This is too vague for me.
> Aside from concerns about the availability and cost of replacement
> hardware,
Has this really been a problem for Debian?
> 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.
There's already another criterion for this, which captures this far
better.
> 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.
> 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.
In summary, it seems like this criterion isn't trying to solve some
particular problem, but it just generally targeted towards cutting
down the number of architectures. I already have doubts as to whether
this is a reasonable premise, but even if I accept it, it seems
neither effective nor particularly well-motivated.
>> > * 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?
>
> Wouldn't this also be an arbitrary penalty on slower architectures,
> though?
Of course it would. But if the point is to set an upper limit on build
time, that would be a good thing and not arbitrary.
> 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?
--
Falk
Reply to: