Differences between revisions 15 and 16
Revision 15 as of 2005-06-12 23:04:10
Size: 2753
Editor: anonymous
Comment:
Revision 16 as of 2009-03-16 03:32:38
Size: 2780
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
See http://lists.debian.org/debian-devel/2005/02/msg00995.html for an RM's perspective. -- ["DDaniels"] See http://lists.debian.org/debian-devel/2005/02/msg00995.html for an RM's perspective. -- [[DDaniels]]

What bottlenecks are created by supporting 11+ architectures? What tasks (if any) require human labour to scale linearly with the number of architectures?

  • Tweaking the installer for each arch
  • Testing the installer for each arch
  • Waiting for a package to build on each arch (sometimes with arch-specific build problems or failures due to a misconfigured autobuilder) before it can get into testing.

What do people commonly think are bottlenecks but really aren't?

What can Debian do to reduce/eliminate these bottlenecks?

Is there a (more) sensible means of including/excluding architectures with each release?

Opinions: By looking at the facts, our past releases, it's obvious that supporting 11+ architectures does not create any bottleneck: no single release has ever been delayed because any given architecture was not ready. There have been instances with the autobuilder infrastructure not coping, but these were usually a result of a) some crucial central bit of infrastructure wasn't ready (we're seeing that now with testing-security) or b) the problem was generic to all architectures, rather than specific to one (seen right before an announced freeze time, where upload spikes tend to generate backlogs on all architectures) -- Wouter Verhelst

Wouter's argument ignores the concept of being nickled and dimed to death. For example, the s390 architecture did not delay the sarge release for months.. but breakage of its autobuilder did delay packages from getting into testing for a week, which delayed a past d-i release by two weeks, which required days of work from various people who would have been working on other release-critical things to solve. This kind of thing happens weekly or daily, I've spent many days working on some architecture-specific problem instead of say, testing security updates or fixing RC bugs. -- JoeyHess

If its true that supporting more architectures creates no bottlenecks, then why not release Pentium 4 and Althon specific builds for 90% of users. (Answer: It's not proven that this gives any performance benefit.)

See http://lists.debian.org/debian-devel/2005/02/msg00995.html for an RM's perspective. -- DDaniels

This proposal seems to be supported by the current release team, ftpmaster team and several DPL candidates for post-Sarge releases. See http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html for the announcement.

In order to prevent any possible bottleneck and to provide high quality releases on all supported architecture, some people think about some writing of DebianSupportedArchitectureCriteria to be filled by a platform in order to be really part of SupportedArchitectures.

Back to ReleaseProposals