Re: How to define a release architecture
On Tue, Mar 22, 2005 at 01:11:32AM -0800, Steve Langasek wrote:
> On Tue, Mar 22, 2005 at 09:36:46AM +0100, Falk Hueffner wrote:
> > 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?
Paying for m68k buildd hardware has generally been the responsability of
the buildd maintainers, with a few notable exceptions (maxing out the
RAM of all our buildd hosts was one). In general, paying for buildd
hardware most certainly has never been the release team's
responsability, so I fail to see why they should worry about it.
> > > 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.
If this problem even exists with hardware that is still available to buy
new, then how would a criterion of 'must be available to buy new' help
aleviate the the problem?
[...]
> 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?
No. They never did, and they never should. The fact that some people are
involved with both DSA and buildd maintenance doesn't mean DSA, as a
group, has anything to do with buildd maintenance.
> And given that none of our current architectures are "dead", why is it
> important to argue this point?
Because the criterion of 'must not require more than two buildd hosts'
would effectively kill off some of our architectures, for no real
reason.
> > > 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?
Yes. We've had buildd hosts ever since Debian 2.0, which is ages old
now, and restricted buildd hosts have apparently not ever become
compromised, while some of our non-restricted hosts have. This makes me
think that the security on buildd hosts is better than those on general
developer-accessible machines, and that, thus, we should not look at
restricted hosts rather than the general accessible machines. Right?
If there are concerns regarding security, I think it's best to name them
and deal with them, rather than imposing arbitrary limits which do
nobody any good.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Reply to: