Re: BREAKING NEWS: Debian developers aren't trusted
Hi,
On Thu Feb 15, 2007 at 13:13:36 +1000, Anthony Towns wrote:
> -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.
I didn't thought of Aurelien, but of a few other persons, who are acting
as buildd maintainers for experimental and non-free packages.
Martin
--
[root@debian /root]# man real-life
No manual entry for real-life
Reply to: