Re: How to define a release architecture
On Mon, Mar 21, 2005 at 05:28:51PM -0800, Steve Langasek wrote:
> 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?
I'm assuming you're talking about m68k here. If not, please correct me.
m68k has been EOLed in desktop hosts for about 10 years now. There are
still people interested in it, who install Linux on their old hardware
for the first time, even today.
I think that pretty much translates to an answer of 'yes' to the above
question.
> 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?
There is some overlap between the groups of 'DSA' and 'buildd admins',
but a) that overlap is not absolute, and b) that overlap is not
necessary.
If the DSA people do not have enough time to spend in keeping stable
security buildds for old architectures running, they are welcome to hand
over buildd maintenance to other people; there are enough experienced
people to take over, if required.
If you're also talking about m68k here, then your point is moot; there
are no people involved with DSA that maintain any m68k buildd host.
> > > * 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?
Yes.
In the specific case of OpenOffice.org, the point is moot.
OpenOffice.org requires some assembly glue, so needs to be ported to
every architecture it runs on; currently, there are OpenOffice.org
packages for i386, powerpc, sparc, and s390; none for any of the slower
architectures, and doing them wouldn't be possible without someone
spending their time on it anyway.
In the general case, as I have said before, I don't think anyone would
take offense at a security announcement being sent out containing
MD5sums for packages for i386, sparc, powerpc, alpha, ia64 and s390,
with a message like 'packages for m68k, mips, mipsel, arm, and hppa will
be announced when ready' if the delay would become unacceptable, or so.
> 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.
Not just that; package build times for equally-sized packages continue
to go up as well, because of increased optimisation.
> 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.
Are there any specific concerns, or is this just a general feeling that
we m68k people might not know what we're doing, security-wise?
If the latter, spelling out a security policy that we have to follow
might be another alternative.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Reply to: