[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:

> > I was quoting a post with actual download numbers that actually demonstrate 
> > that the vast majority of users are on i386: see http://blog.bofh.it/id_66.

> But that doesn't show what you said you believe, which is that
> supporting other archs slows the release.

It's not actually all that difficult to show that there's a positive,
roughly linear correlation between the number of release archs and the
magnitude of certain problems that are potential release delays:

- new versions of packages are not promoted to testing until they're
  in sync on all archs
- all release-critical bugs in packages are resolved by either removing the
  package from testing (not always an option) or by getting a new version of
  the package into testing
- a buildd for a single arch that is broken with respect to the package in
  question can therefore cause a delay in fixing a single release-critical
  bug in testing
- the chance of a bug fix being held out of testing because of a buildd bug
  on some arch is roughly equal to the chance of it being held out because
  of a bug on a particular arch, times the number of archs[1]
- when the delays cause our bug closure rate to be lower than the rate at
  which new release-critical bug reports are opened, we have a problem.

That said, however, there is not much evidence to support the idea that
dropping architectures from the list of release candidates is going to get
us to the release any faster.  Not only is there the possibility that the
responsiveness of individual buildd maintainers should outweigh popularity as
a factor in deciding which architectures to support, there's also the issue
that the biggest blocker for sarge currently, the lack of testing-security
buildd support, affects all but *two* architectures.  Somehow, I don't think
the idea of releasing with only i386 and sparc would be very popular, even
if I was inclined to do so.

> Easy to say.  How many RC bugs have you fixed recently, and if we
> dropped the other archs, how many would you have fixed?

<ahem> do we get to count on his behalf CAN-2005-0011, a security bug in
kdeedu which is currently blocked from reaching testing because the quantlib
package he maintains needs for someone to manually adjust the buildd timeout
on mips and mipsel?

> > - 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.

Prior to release, security bugs are RC bugs that are handled by the testing
security team and the release team.  While we would not delay the release on
account of security bugs alone (since they can be fixed post-release), they
are bugs that get tracked by the release team.

> > - scarce resource such as release managers, ftp admins, ...
> > if we have to look after arches that are *not really used*.

> All of whom have said that this doesn't actually slow them at all.

Hmm, no; I've only said that dropping archs because of build problems
affecting individual, arbitrary packages is a stupid strategy for getting us
to release.

Steve Langasek
postmodern programmer

[1] With other minor factors that probably balance each other out, such as
identical simultaneous breakage on multiple buildds that reduce the impact
by allowing fixes in parallel or as a batch, vs. some buildd maintainers
running multiple buildds who may have less time to tend an individual arch
because of the total number of archs being supported

Attachment: signature.asc
Description: Digital signature

Reply to: