On Mon, Mar 14, 2005 at 07:59:43PM +0000, Alastair McKinstry wrote: > > AFAI can tell, anybody can host an archive of packages built from stable > > sources for a scc or unofficial port. And - if I read the conditions on > > becoming a fully supported Debian arch right - then having security support > > for an external pool of this arch is a good indicator that it should be a > > fully supported stable release (amongst other things). > The plan as proposed is that the Debian scc ports are purely builds of > unstable. Hence this build out of the last release (e.g. etch) becomes a > subproject of a second-class project of Debian. It effectively has > little credibility. Well, the release team are not the only Debian developers with credibility, surely? Not everything needs to go through us; if the project has the will to do stable releases of these architectures, in spite of the release team being unwilling to delay other architectures while waiting for them, then it should be very possible to provide full stable releases for these architectures. Clearly Joey Schulze, our Stable Release Manager and Security Team lead, feels that once a stable release has been made, the architecture count is not a major obstacle; so in theory a late-releasing per-arch version of etch should be just as supportable as the RC target arches? I tend to suspect that if an arch needs to be dropped from the release for one reason or another, without the active attention of the release team the "releasable" sources for that architecture will diverge rather rapidly from what's being shipped in testing; which is why I think that, if people really do depend on the full stable release semantics (including security support and point releases) for each of these architectures, it's best to try to get them included in the main release process -- I'm just not willing to delay etch as a whole when architectures start to lag behind, because I don't think that's what's best for the vast majority of our users. > The challenge, however, is to do this _within Debian_, so that > maintainers will apply patches to their packages that are required for > minor ports, and keep version skew and hence complexity to a minimum. > Hence we should do what we can to keep minor ports _within_ debian, even > mostly symbolic gestures such as keeping Debian SCC ports in > ftp.debian.org/ports rather than 'offsite' in scc.debian.org, etc. > (Note: I agree that mirrors should be capable of doing partial mirrors, > rather than having to mirror the whole of ftp.debian.org, though). (hopefully if I repeat this enough, people will stop conflating the two concepts: ) The plan to divide architectures for mirroring purposes has existed since long before anyone talked about dropping architectures for etch. There will be release architectures distributed from $ports.debian.org for etch; and whether or not an architecture is considered a "first-class citizen" (or "core") architecture for mirroring purposes is orthogonal to whether or not it's a release arch, except that all FCC architectures will be release architectures. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature