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

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



On Wed, Mar 16, 2005 at 12:50:31PM +0100, Martin Schulze wrote:
> > We project that applying these rules for etch will reduce the set of
> > candidate architectures from 11 to approximately 4 (i386, powerpc, ia64
> > and amd64 -- which will be added after sarge's release when mirror space
> > 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.
> 
> Since this is the first time I hear that so much of  "architecture
> coordination" is required for testing, could you elaborate how much
> time this is referring to and which problems the release team has
> faced in particular?  I'd be glad if somebody could propose an
> alternative solution, as dropping most architectures would be a large
> regression for Debian and its community.

I think that all they mean is "the complicated act of getting, and
keeping, all architectures in sync in testing".  For instance, getting
large packages built in the same version on every architecture,
discovering an architecture-specific bug, and redoing the whole thing
before it or any of its dependencies can migrate to testing.  Not a new
problem, especially for anyone reading debian-release.

> It's also an interesting thought how many architectures will suffer
> from the _all dependency trap when maintainers don't care about crap
> architectures anymore that won't be released at all.

I imagine most of the ports would have their own copy of binary-all
in this scenario.  Or additional binaries would be maintained in the
main binary-all.


-- 
Daniel Jacobowitz
CodeSourcery, LLC



Reply to: