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

Re: Canonical and Debian

On Mon, Jun 06, 2005 at 02:12:00PM -0400, Stephen Frost wrote:
> * Steve Langasek (vorlon@debian.org) wrote:
> > Clone yourself and make yourself a slave to the buildds for 7 or 8
> > architectures, so that the release team doesn't have to.  Neither the

> Whoah, whoah, whoah, is this actually an option?  Last I checked that
> answer was 'no'.

Well, I think there's still a moratorium on human cloning in the US, isn't

> There seems to be a few different reasons for this, but one of the big
> ones is wanna-build access, I believe.  This is because of limitations of
> the current wanna-build framework, which may have now been resolved?

I wasn't necessarily referring to being buildd admins.  The biggest time
sink, AIUI, is keeping machines of reasonable power up and running, which
ought to be the responsibility of the local admin (porters, presumably);
it's not lack of w-b access which causes buildd starvation for those
architectures that have that problem.

Yes, I imagine the w-b infrastructure's lack of scalability was probably a
factor in being choosy about what machines to accept as buildds, but there
are certainly going to be other factors that scale linearly with the number
of buildds, so I don't foresee the w-b admins ceasing to concern themselves
with getting the most bang per buildd.  But while everyone's fretting over
whether the w-b admins will allow m68k buildd #15 to connect, we have the
following architecture problems right now, in no particular order:

- alpha: one buildd, able to keep up with current package volume; no spare
  buildd due to the principal candidate being inexplicably unbootable now
  (oh yeah, btw, the primary failed and was off-line for a day, a week
  before release); no porter machine available.
- hppa: one buildd, keeps up with package volume, but no backup buildd and
  gdb seems to kill its kernel (yay); one porter machine.
- sparc: one buildd which is not consistently able to keep up with the
  volume of incoming packages; no backup buildd, no additional porter
- s390: one buildd, which consistently cannot build gtk+2.0 because it only
  has 2GB of space available for builds and gtk+2.0's requirements have
  recently exceeded this; a second possible buildd is not yet hooked into
  w-b because of what appear to be administrative details.  (two porter
  machines available, though.)
- powerpc: one buildd that's getting long in the tooth; one porter machine.
  (obviously a readily available architecture, but that doesn't really help
  much if the only configured buildd is down and it takes a week to
  designate & configure a new one.)

I have a really hard time believing that these architectures are blocked
from adding a second buildd due to security or scalability concerns alone
when at the same time we have roughly a dozen m68k buildds...

Oh, you'll also note that the traditional "slow" architectures (mips,
mipsel, m68k, arm) aren't on this "problems" list.  That's because a *lot*
of effort has been put into providing sufficient parallelization for each
architecture; the ongoing cost to *maintain* these parallel buildds is
higher than to maintain a single buildd, and given that each of arm, mips,
and mipsel have had instances over the past year where they were
short-handed, I don't know how realistic it is to expect that they'll stay
caught up through etch's lifetime.

The second most significant area of concern, for me, is having people being
proactive about dealing with per-architecture build failures.  There's no
particular reason that should be the buildd admins' or the release team's
area of responsibility, either; all it requires is people who know what
they're doing to file sensible bug reports without gratuitously duplicating
efforts, and people who know the architectures to help the maintainers sort
out bugs.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: