Re: Bits (Nybbles?) from the Vancouver release team meeting
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
Reply to: