Hi Aurélien, On Mon, Mar 14, 2005 at 10:56:51AM +0100, Aurélien Jarno wrote: > Steve Langasek a écrit : > >The much larger consequence of this meeting, however, has been the > >crafting of a prospective release plan for etch. The release team and > >the ftpmasters are mutually agreed that it is not sustainable to > >continue making coordinated releases for as many architectures as sarge > >currently contains, let alone for as many new proposed architectures as > >are waiting in the wings. > Would it be possible to have a list of such proposed architectures? I think this has already been answered, by someone who knows better than I. > >This change has superseded the previous SCC (second-class citizen > >architecture) plan that had already been proposed to reduce the amount of > >data Debian mirrors are required to carry; prior to the release of sarge, > >the ftpmasters plan to bring scc.debian.org on-line and begin making > >non-release-candidate architectures available from scc.debian.org for > >unstable. > If scc.debian.org is not mirrored, it would be possible to have much > more place than now. Does it means that more architecture could be > supported? I am thinking of the SH port that would need to separate > tree, if I remember correctly. Well, first, I don't think anyone is keen on the idea of an scc.debian.org that *doesn't* get mirrored; we know it won't be mirrored as extensively as ftp.debian.org will be, but we can aspire to it being useful enough to people that it could be mirrored as extensively as ftp.debian.org *currently* is. (Though probably a little less, in practice.) Adding a bunch more ports (the SH port is basically 4 different ABIs and counting, at this point) with *no* cost/benefit analysis on the mirroring front doesn't seem like a good idea to me. But I'm not sure that the sh ports are far enough along that mirror space is the limiting factor either; since they have 4 different ABIs to support, my understanding is that the porters (and the buildds) are spread rather thin. > > Note that this plan makes no changes to the set of supported release > > architectures for sarge, but will take effect for testing and unstable > > immediately after sarge's release with the result that testing will > > contain a greatly reduced set of architectures, according to the > > following objective criteria: > I would add: > - there should be at least 2N buildd admins for this architecture. A lot > of problems with buildds are caused by buildd admins unavailable at the > same time for a given arch. I don't know that 2N buildd admins is necessary, but I think having >1 buildd admin for a port is a good idea. I'm not sure it should be mandatory -- a lot of recent per-arch delays have actually been tied to the availability of *local* admins, for instance, not to buildd admins per se. It bears thinking about what the exact problem being solved here is that isn't already solved by requiring hot-spare buildds. > >Architectures that are no longer being considered for stable releases > >are not going to be left out in the cold. The SCC infrastructure is > >intended as a long-term option for these other architectures, and the > >ftpmasters also intend to provide porter teams with the option of > >releasing periodic (or not-so-periodic) per-architecture snapshots of > >unstable. > My primary desktop machine is an i386, but it was sometimes ago and for > a limited period of time and hppa machine, because my i386 had problems. > It allowed me to continue my work on Debian packages. In the case this > new infrastructure is set up, does upload from a SCC architecture to > unstable would still be allowed? If no, source only upload must be > allowed again. Since non-RC (release candidate) architectures are going to be in the same unstable tree as the RC architectures (uploads to ftp-master, etc.), I don't see any reason that this would be disallowed. > >- there must be a sufficient user base to justify inclusion on all > > mirrors, defined as 10% of downloads over a sampled set of mirrors > AFAIK, only i386 currently meet this criterion. Of the architectures currently in sarge, that's correct. It's assumed that amd64 will easily meet this 10% mark for etch. (If it doesn't, then the cut-off probably has to be re-thought, since it doesn't make much sense to have a 1/11 split between ftp.d.o and scc.d.o, *particularly* when the 11 archs together *would* most likely account for > 10%.) > BTW, I am not sure this is really a good way to measure the use of an > architecture, mainly because users could use a local mirror if they have > a lot of machines of the same architecture. How about using popcon *in > addition* to that? This isn't being used to measure the use of the architecture; it's being used to measure the *download frequency* for the architecture, which is precisely the criterion that should be used in deciding how to structure the mirror network. > >To be eligible for inclusion in the archive at all, even in the > >(unstable-only) SCC archive, ftpmasters have specified the following > What about experimental? experimental would also be available. > >architecture requirements: > 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. You could say that "there must be a developer-accessible machine for the architecture" without specifying "debian.org"; but I'm not sure that we should *require* this, either. Particularly for ports that are waning and are not expected to become RC architectures in the future, I think porters should be free to decide whether to spend the effort on maintaining such a machine since its absence only hurts that port, not the release. > This is important if you want the developers could fix bugs on their > package for SCC architecture. This is currently not the case of the > alpha port, and that sucks. Well, FWIW, I think you'll find that the debian-alpha mailing list is very responsive to maintainers who need help with alpha-specific package bugs. > That let me raise a problem I see with such an infrastructure. Imagine > an FTBFS on an SCC architecture (let's say arch X needs an autotools > update). If it is not possible to have a high severity for this bug > (because it is "only" an SCC arch) , I am almost sure that it would be > ignored by a lot of developers. That would say that all SCC > architectures will be quickly unusable... a) Just because it's not release-critical doesn't mean (most) maintainers will ignore it; I think the majority of these bugs will be fixed by the maintainers. b) Just because it's not a release arch doesn't mean the porters can't NMU to fix problems if the maintainer isn't fulfilling his responsibilities. > I think that supporting a lot of architectures is an important > difference between Debian and other distributions. Changing that could > have a dramatically influence of what users think of Debian. IMHO, such > an important decision should not be taken by a few developers. 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? I agree that our architecture coverage is important. I don't know if stable support for all of these architectures is important, but I *do* know that stable support for all of these architectures costs us in terms of the release cycle. The length of our release cycle is also an "important difference" between Debian and other distributions, but it's not a positive one for us. > Maybe a vote is need... I'd much rather work towards a consensus. Cheers, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature