Scripsit Steve Langasek <[EMAIL PROTECTED]> >> I would add as for the core set architecture: >> - there must be a developer-accessible debian.org machine for the >> architecture.
> This gets a little tricky for non-RC architectures, because if it's not > already (or currently) a released architecture, we have no stable distro > that can be installed on it, which means we have no security support for > it; without security support, DSA isn't willing to maintain it, which > means they probably aren't going to want to put a "debian.org" name on > it, either -- and they certainly won't want to give it privileged access > to LDAP. So how can an architecture ever become releaseworthy? It will not get release-certified before it has a a debian.org machine, and it cannot get a machine in debian.org before it has a stable version with security support, and it's not allowed to create a stable version and provide security support for it before it has been release-certified. > Well, if we wanted to make the decision without the input of developers, > announcing it on d-d-a in advance of implementation isn't a very > effective way to make that happen, is it? If you wanted to make the decision _with_ the input of developers, why did all the powers that be vehemently deny that the number of architectures was a problem for the release schedule, right until everyone turned on a platter and presented this fait accompli? > I agree that our architecture coverage is important. I don't know if > stable support for all of these architectures is important, It is. > but I *do* know that stable support for all of these architectures > costs us in terms of the release cycle. The solution to that is to decouple the secondary architectures from the release cycle of the main architecture. There is no visible reason why the solution has to include a ban on making any stable release for a minor architecture at all. -- Henning Makholm "Hele toget raslede imens Sjælland fór forbi."
