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

Re: Canonical and Debian

Le mardi 07 juin 2005 à 02:12 -0700, Steve Langasek a écrit :
> 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
>   machine.
> - 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.)

Thanks for this explanation, it makes things look much clearer to me
than "the arch needs <insert random condition here> to be supported".

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

With the constant flux of donation proposals, they could clearly be
added. However, if the buildd admins and administration team refuse to
handle them, I fail to see how the situation can be solved.

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

This isn't fair. Instead of throwing out these arches, why not let them
in the current state while there's some effort to maintain them, and if
these efforts actually slow down, then drop the architecture at that

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

I agree. This is the maintainers' duty, not the release team's. And if
the problem is too complicated to solve for the maintainer, someone
willing to support the architecture has to help. If such a person cannot
be found, this is a sign the architecture cannot be supported in Debian.
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
   `-  Debian GNU/Linux -- The power of freedom

Reply to: