Steve Langasek <[EMAIL PROTECTED]> wrote: > On Mon, Mar 14, 2005 at 10:06:35AM -0600, John Goerzen wrote: > >> I also have no objection to releasing stable later on some archs, or not >> at all, of nobody from those archs works to do it. > >> I do object to preventing those archs from releasing stable, and from >> being supported at all by the security infrastructure. > > Please clarify what you think a late-releasing stable arch is going to > look like, in contrast to what has been proposed, given that keeping > release architectures in sync is the only thing we have that guarantees > the sources in testing (and therefore in stable) are in a releasable > state for each of those architectures.
I guess the late-releasing stable arch would very much look like the core architectures, just that its buildd's took more time to do the compilation, and that there are different promises to our users on this arch (security support by the porters team "as good as possible"). In case there are bugs in the release that are RC bugs for the late-releasing, tier-2 arch, but do not apply to the main arches (or are not RC for them), there are two possibilities: a) drop that package (and (build-)dependencies) from that arch. That might well be a working alternative; arches that are used for embedded devices, or mainly for servers/firewalling/... might well do without KDE or some number-crunching application. b) Provide the possibility to have a "stable-plus-tier-2-patches" branch in the archive, with a very limited number of source packages that are derived from stable with the necessary patches for tier-2 arches. In the long run, it might be even possible to get along with the stable sources alone, plus a second, tier-2-specific diff.gz - if I'm not mistaken it is planned to enable dpkg to work with a more flexible format for source packages. If there are such source changes, the porters must rebuild the parts of the archive that build-depend on the changed packages, guaranteeing the consistency of the release. But this won't be a very harsh requirement, since most of the arch-specific RC bugs are FTBFS, anyway. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
