Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 08:54:36PM -0800, Thomas Bushnell BSG wrote:
> Dirk Eddelbuettel <edd@debian.org> writes:
> > - cpu cycles (witness Wouter's request to compile big packages
> > rarely),
>
> So you're saying that if we dropped the mips buildd's we'd have more
> cycles for other archs?
No, he's saying that if we dropped the slower architectures we'd be able
to do more frequent updates of large packages, such as KDE.
However, this is false. You'd get
* Angry mirror administrators that don't like the fact that users now
have to download a *much* larger amount of data every day for their
daily updates, thus eating a larger part of their bandwidth,
* Angry users who, like me, have a traffic quota on their Internet
connection and who'd get problems staying within the quota if they
want to keep up with unstable,
* Problems keeping track of all those versions, and the relation to when
bugs were fixed (there are always users who do not have the latest
version of a package installed and still file bugs).
* Problems with your own development pace, because you'd be spending
more time on performing package builds and making sure they get
updated correctly than you'd be spending on the improvement of those
packages.
As I said before, this is not just a buildd problem, it's a sensible
approach to maintaining large packages in general; and if you as the
maintainer of a large package really made a stupid mistake and need to
upload a package within two hours after the previous one, then so be it.
We only request that you try to avoid it as much as possible.
> > - security response time (more builds to do)
>
> Which DSAs came out later than they should have because of this
> supposed delay? Nor could this possibly slow release.
In fairness, this is not just a fairy tale. DSA's are sent out for all
architectures at once; if a package requires two days to build on the
slower architectures (there are packages for which this is true), then
the DSA will take two days to be prepared. I should note that security
builds are given priority, however, and are done on the fastest machines
in the architecture's buildd pool.
That said, your statement that it could not slow release is, of course,
true.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Reply to:
- References:
- [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]
- From: Clint Byrum <cbyrum@spamaps.org>
- Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
- From: Dirk Eddelbuettel <edd@debian.org>
- Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
- From: Wouter Verhelst <wouter@debian.org>
- Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
- From: Brian Nelson <pyro@debian.org>
- Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
- From: Dirk Eddelbuettel <edd@debian.org>
- Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
- From: Matthew Palmer <mpalmer@debian.org>
- Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
- From: Dirk Eddelbuettel <edd@debian.org>
- Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
- From: Thomas Bushnell BSG <tb@becket.net>
- Prev by Date:
Re: Let's remove mips, mipsel, s390, ...
- Next by Date:
Re: Let's remove mips, mipsel, s390, ...
- Previous by thread:
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
- Next by thread:
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
- Index(es):