[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits (Nybbles?) from the Vancouver release team meeting



On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> 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

That makes sense.

> Therefore, we're planning on not releasing most of the minor architectures
> starting with etch.  They will be released with sarge, with all that

That doesn't.  I see no problems with making an initial etch release
consisting of whatever archs are ready, SCC or not.  If a given arch
later has a working etch distribution and installer, why not publish an
etch release for it, even if it is on SCC?  There are serious problems
with unstable on some machines.

Moreover, I haven't seen anything about the security implications of
relegating so many archs to SCC, and to unstable-only status at that.

> - the release architecture must have N+1 buildds where N is the number
>   required to keep up with the volume of uploaded packages
> 
> - the value of N above must not be > 2

It seems to me that if an arch can keep up with builds, why impose this
artificial restriction?

> is freed up by moving the other architectures to scc.debian.org).
> This will drastically reduce the architecture coordination required in
> testing, giving us a more limber release process and (it is hoped) a
> much shorter release cycle on the order of 12-18 months.

That is a Good Thing.  However, why eliminate out of hand the
possibility of ever making stable releases for the other 7 archs?  Even
if they release later than those 4?

> ftpmasters also intend to provide porter teams with the option of
> releasing periodic (or not-so-periodic) per-architecture snapshots of
> unstable.

I'd rather see the option to produce the same per-architecture snapshot
of testing as everyone else uses; that is, an etch release.

> distributed via ftp.debian.org itself.  The criterion for being distributed
> from ftp.debian.org (and its mirrors) is roughly:
> 
> - there must be a sufficient user base to justify inclusion on all
>   mirrors, defined as 10% of downloads over a sampled set of mirrors

That will be a self-fulfilling prophecy, won't it?  Fewer people would
ever download a SCC arch, so how would it ever be possible for a SCC
arch to break into ftp.debian.org?



Reply to: