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

[Colin Watson <cjwatson@debian.org>]

On Mon, Mar 14, 2005 at 08:58:46AM -0600, John Goerzen wrote:
> On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> > 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?

This paragraph from the proposal may bear repeating, since it was kind
of buried deep in the middle:

  Also, since the original purpose of the SCC proposal was to reduce the size
  of the archive that mirrors had to carry, the list of release candidate
  architectures will be further split, with only the most popular ones
  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

Under this proposal, being on the SCC mirror network would not in itself
cause an architecture to be ineligible to release as part of etch.

> > - 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?

I'm not sure where this restriction came from, and I didn't think to
question it at the time ...

> > 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.

I wonder if we could simply use the current support in britney for
declaring that an architecture isn't keeping up to date and that any
problems with it shouldn't block the rest of testing. I'm not sure what
the consequences of that would be for the usability of testing on
non-releasing architectures, though; it might make them worse.

-- 
Colin Watson                                       [cjwatson@debian.org]