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

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



On Tue, Mar 15, 2005 at 04:00:13PM -0800, Steve Langasek wrote:
> Once you start talking about having divergent packages between
> architectures, a lot of the reasons I'm hearing from people about why
> they want Debian to *do* releases for these archs seem to dissipate,
> because they no longer have assurances that the OS is "the same" on
> different hardware.  If unstable-only ports aren't enough, and the
> sources aren't going to match in the testing/stable versions, maybe we
> start to think about wanting to implement parallel infrastructure for
> these other ports, as well -- and maybe it's under the Debian umbrella,
> and maybe it isn't; I think it's better if it *is* still "Debian", but I
> think we need to be realistic about the fact that once we have to trim
> those architectures from the list of architectures being released in
> lockstep, we've removed the pressure that keeps the sources in sync and
> it's no longer going to match the stable Debian that we're providing on
> other architectures.

I don't buy the first half of this paragraph.  For me, the killer
features of Debian stable releases are:

  - Been through some amount of settling-in time, either via a freeze
    or testing.  This acts as an effective quality floor.
  - Support (medium-term, I know first hand that long-term is less than
    doable) from the security team.
  - "Is Debian".  Even if it isn't the same versions of everything as
    some other Debian box in that other place, it's still going to work
    basically the same.  I work on woody, sarge, and sid boxes; they
    all share the fuzzy Is-Debian feeling.

Unstable-only ports don't do the first two.  Stable ports, even if they
diverge somewhat from other Debian stable releases, do all three.  The
more infrastructure we can provide to allow porters to take advantage
of Debian's fewer-arch stabilization, the better quality the port
releases will be.

I've suggested (briefly) a slaved testing which tries to enforce sync
with the main testing archive.  Similar things could be done for
stable.  It's been a long time since I was on the front lines of a
port, so I don't know how much manpower the ports have to work with
nowadays; but I bet they could manage this much.


-- 
Daniel Jacobowitz
CodeSourcery, LLC



Reply to: