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

Re: BREAKING NEWS: Debian developers aren't trusted

-vote dropped

On Wed, Feb 14, 2007 at 03:06:01PM +0100, Martin Zobel-Helas wrote:
> > Maintaining a buildd isn't trivial, there's:
> > 
> >     - making sure they don't get rooted, and their builds compromised
> >     - keeping the chroot up to date
> >     - keeping in sync with w-b / sbuild changes
> >     - keeping in sync with the infrastructure upstream (building from incoming,
> >       access to the buildd.d.o, etc)
> >     - keeping the hardware available and running
> >     - keeping the buildd building packages that will work
> > 
> > It's not /that/ hard either (even if it's not something I could do without
> > a chunk of learning), but basically, yeah there are technical constraints.
> > The only policy constraint is that we're aiming to keep the number of
> > buildds limited to two or three per architecture (where possible); the
> > social constraints are mostly about convincingly demonstrating that the
> > technical constraints will be met on an ongoing basis.
> i think someone running more than one autobuilder for more than _two_
> years now (okay, not for the officical archive, but i see that as
> nonrelevant here) demonstrats very good that he mets your mentioned
> technical constraints.

AIUI, Aurelian doesn't have the capability to run a non-emulated arm
buildd. While http://blog.aurel32.net/?p=25 is a good demonstration
of some things, I don't think it's the level of buildd we want for our
release architectures.

In general, I could pretty easily imagine a buildd that fails every one of
those points still being suitable for a non-release arch for two years.


Attachment: signature.asc
Description: Digital signature

Reply to: