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