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

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

Hi Andreas,

On Mon, Mar 14, 2005 at 07:37:51AM +0100, Andreas Tille wrote:
> On Sun, 13 Mar 2005, Steve Langasek wrote:

> IMHO all these facts with exception of those "social" facts I marked (?)
> are fullfilled by Sparc.

For reference, the killer for most archs is the "98% built" criterion;
from today's numbers:

wanna-build stats:
  alpha:        97.57% up-to-date,  97.59% if also counting uploaded pkgs
  arm:          92.12% up-to-date,  92.15% if also counting uploaded pkgs
  hppa:         97.66% up-to-date,  97.68% if also counting uploaded pkgs
  hurd-i386:    35.59% up-to-date,  35.59% if also counting uploaded pkgs
  i386:         99.83% up-to-date,  99.83% if also counting uploaded pkgs
  ia64:         97.39% up-to-date,  97.41% if also counting uploaded pkgs
  m68k:         97.75% up-to-date,  97.86% if also counting uploaded pkgs
  mips:         96.74% up-to-date,  96.79% if also counting uploaded pkgs
  mipsel:       93.01% up-to-date,  93.01% if also counting uploaded pkgs
  powerpc:      97.99% up-to-date,  98.00% if also counting uploaded pkgs
  s390:         94.31% up-to-date,  94.31% if also counting uploaded pkgs
  sparc:        95.77% up-to-date,  95.77% if also counting uploaded pkgs

[curious that ia64 is lower than some others right now -- when we looked
last week, it was above 98%, so maybe etch would have a *different* 4
architectures. ;)]

This may be fixable for one or more architectures for etch by getting a
handle on any existing buildd problems, which I'd personally be happy to
see happen, but we also have to consider that there are some bits (like
ftp-master.d.o itself, as well as toolchains/kernel synchronization)
that just don't scale well to the number of architectures we currently

The 98% mark may seem a little high, but in fact it's not.  Note that
there's been a thread on debian-devel just this week about autobuilders
holding up release-critical bugfixes, and the architectures in question
are still well above 90% -- and they're not the only architectures
delaying RC fixes, they're just the ones that stand out enough to flame
about.  Based on the experience we've had trying to keep sarge on track,
setting the barrier high for etch is definitely in our best interest,

For the specific case of sparc, it's worth noting that this architecture
was tied for last place (with arm) in terms of getting the ABI-changing
security updates for the kernel; it took over 2 months to get all
kernel-image packages updated for both 2.4 and 2.6 (which is a fairly
realistic scenario, since woody also shipped with both 2.2 and 2.4),
which is just way too unresponsive.  The call for sparc/arm kernel folks
in the last release update was intended to address this; correct me if
I'm wrong, but to my knowledge, no one else has stepped forward to help
the kernel team manage the sparc kernels.

> >- there must be a sufficient user base to justify inclusion on all
> > mirrors, defined as 10% of downloads over a sampled set of mirrors
> Hmmm, regarding to the fact that i386 makes a real lot of percentage it
> might be a quite hard limit to have 10%.  I guess this reduces the number
> of supported architectures by fitting to a previousely defined number
> of architectures we are willing to support.

This point is *not* about supported architectures, only about
architectures carried by the primary mirror network.  We did consider
having a single set of requirements for both "release architectures" and
"primary mirror architectures", and the structure of the announcement
might still reflect that, but I couldn't justify using "percent market
share" as a straight criterion for release architectures.

> >- 5 developers who will use or work on the port must send in
> > signed requests for its addition
> I'm DD and use Sparc (but do no active development to support this
> hardware).

Well, sparc is not in any danger of being dropped from SCC. :)  As I
said, none of the current sarge candidate architectures are.

> In general I would like to say that supporting a lot of architectures was
> an important difference between Debian and other distributions.  I know the
> drawbacks of this but I just do not want to hide my opinion that I do not
> like the idea of reducing the number of supported architectures that 
> drastical.
> IMHO the effect would be that people will start forking Debian for porting
> issues and we will loose the power of those porters while they will spend
> time for things they would not have to do else.

I certainly agree that portability is one of Debian's selling points,
and I also have a "pet" architecture that doesn't appear to make the
cut for etch; but I don't think it's a coincidence that the release
cycle got longer when we doubled the arch count between potato and
woody, and I *know* it's not a coincidence that we have a long release
cycle for sarge while trying to wrangle those same 11 architectures.
This proposal is a response to the reality that right now, the per-port
cost on certain "central" teams (and hardware) in the project is high,
and does not scale to handle a large number of architectures.
Personally, I'd love to see our porter teams rise to the occasion and
prove that we can release etch in 18 months with 8 architectures meeting
these criteria instead of 4; but the first step is to shift the burden
onto the porters, which is not where I believe it is today.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: