On Mon, Mar 14, 2005 at 03:57:40PM -0800, Steve Langasek wrote: > Hi John, > > On Mon, Mar 14, 2005 at 10:06:35AM -0600, John Goerzen wrote: > > On Mon, Mar 14, 2005 at 10:52:29AM -0500, Stephen Gran wrote: > > > Let me try to be clear. I am not necessarily in favor of dropping > > > arches. I am opposed to having portability issues make new releases > > > drag on forever, and slowing security releases. We have been told > > > I am too. > > > I have no objection to releasing security updates for the 4 "main" archs > > with announcements, and the rest as soon as they're compiled (which > > should be just about as soon for most). > > > 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.
Did you read may tier-2 arches building from testing, with their own per-arch testing scripts proposal ? Once a release is made, the stable release is mostly untouched, and unstable/testing goes its own way to the next release. Those tier-2 arches that desire to have a stable release will fork a new frozen or whatever distrib, and resolv (or drop) the remaining problematic packages that stopped them from being release ready, and upload fixed packages to stable-proposed-updates, which get built on the tier-1 arches, and tested for regression. Once there is time, a stable point release can happen, which would include those arches that have made it. The different between this scenario, or another one of the kind, would be to let the door open to the tier-2 arches, while your proposal clearly shuts the door to them and let them out in the cold. Now, the other aspect is security update, and here again instead of saying there will be no security update for tier-2 arches, and they are left to fend for themselves, why not say that security updates will not wait for tier-2 arches, and release as soon as the embargo allows. The main point here is to get tier-2 arches with people interested in security updates to provide folk to work on this *AND* to allow them to get advance notice of the security updates, which is often a couple weeks, in order for them to start preparing for the security fixes. Also security fixes are usually not arch-specific, and having the tier-2 arches each doing their own security support in their corner is clearly counter productive, and multiplies by 8 the workload involved. If we are not going to drop tier-2 arches totally, which i belive will bring a fork of debian in the long run (but who then gets to keep the debian name ?), then we need at least opt-in support for testing, stable release and security, even if delayed or second-level support for those. And BTW, despite my repeated call for help, i have not yet found anybody with x86 experience to help me comaintain the parted package, as thus i propose we should drop x86 from tier-1 arches instead of letting it eat up our users data without warning :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
