On Wed, Feb 14, 2007 at 11:16:56PM +1100, Hamish Moffatt wrote:
> On Wed, Feb 14, 2007 at 09:15:17PM +1000, Anthony Towns wrote:
> > On Wed, Feb 14, 2007 at 07:12:31PM +1100, Hamish Moffatt wrote:
> > > Then you don't see any conflict of interest between the arm buildd admin
> > > and the ftp-master?
> > No, I don't. I don't see any conflict of interest in being a package
> > maintainer and an ftp-master, either.
> Do you think an ftp-master should admit his own packages through NEW
> processing, hypothetically?
That's not a hypothetical case, and when it comes up we routinely get someone
else to process them.
> Fine, I agree that this was not a decision that one maintainer should
> make unilaterally. I don't think that another project member
> unilaterally banning it without discussion is right either. How about a
> polite request to stop while the issue can be discussed and a consensus
> formed?
If something potentially dangerous is happening, you stop it first,
then talk about it, IMO. Politeness is something you get to expect only
when you give it.
> > There are additional problems with running a rogue autobuilder, such as
> > unavailability of build logs, unreproducibility of builds, and unusability
> > of the builds by the security team. Aurelian's buildds had the additional
> > problem that they'd repeatedly rebuild packages they'd already uploaded,
> > which isn't really useful. There's a potential issue wrt whether the
> > build environment is secure as well, but I'm not familiar enough with
> > that on any level to comment in any detail. All these could be solved
> > by someone committed to making sure they do at least as good a job as
> > the regular buildd network though.
> Aren't most of these problems (rebuilding packages unnecessarily and
> unavailability of logs) due to the difficulting getting new buildds
> added to the regular network?
Aurelian's autobuilders would build a package, upload it, then build it
again and upload it again, repeatedly. That's something that's pretty
easily fixed on the buildd side. Likewise, making the logs available
just means sticking them up on a webserver somewhere -- it's good to
have a central interface, but it's not crucial.
> Are there technical reasons why we can't
> add new buildds more freely, or only political/social reasons?
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.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature