[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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,

     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 -- with thanks to fortune

Reply to: