On Wed, Feb 14, 2007 at 07:12:31PM +1100, Hamish Moffatt wrote: > On Wed, Feb 14, 2007 at 11:33:19AM +1000, Anthony Towns wrote: > > On Tue, Feb 13, 2007 at 11:11:55PM +1100, Hamish Moffatt wrote: > > > On Tue, Feb 13, 2007 at 06:00:12PM +1000, Anthony Towns wrote: > > > > On Tue, Feb 13, 2007 at 06:35:07PM +1100, Hamish Moffatt wrote: > > > > > > Uh, what's this if not peer review? > > > > > It's not peer review when we discuss it later and none of us (including > > > > > you) have any power to do anything about it, except via long drawn-out > > > > > political processes. > > > > Err, I could change it right now if I thought that was the best thing > > > > to do. I'm not, for the reasons I've already commented on. > > > Right, you could change dak. You can't/won't/? fix the process by which > > > the current restrictions were added though. > > I don't think that's broken in the first place. > 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. I suppose I could see a potential conflict of interest in being the buildd admin to introduce a major change, as well as the ftpmaster to allow it; but in being the ftpmaster to block someone else introducing a fairly questionable change, as well as a buildd admin? No, I don't see a problem. > > But there's improvements in the pipeline for that > > (which, yes, I do need to mail about), and afaics running a qemu based > > buildd does nothing to improve it. > The fact that Aurelien's buildd was running on qemu seems to be beside > the point (and wouldn't even be detectable if he hadn't blogged about > it); it's the fact that he was running a "rogue" buildd. Uh, no. That it's run under qemu introduces a significant risk that the builds may be unreproducible or unusable on real systems (this risk deferred the use of an emulator for autobuilding m68k until it was decided it wouldn't make the etch release, eg). Personally, I think that risk can be proven to be largely hypothetical, but you don't mess with a release arch on a hunch like that, you find some way to demonstrate you're right first. 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. > I mean, how dare he try to help the project in this way. There's nothing wrong with trying to help the project, the problem is when you don't give a damn about the problems your attempts cause. Having a debate on the lists or running a GR doesn't help show qemu builds are workable, and doesn't help your build system provide the features the existing build network does that other developers rely on. I find it pretty hard to see this as "trying to help the project", rather than "trying to win your rather pointless fight with the buildd admins". I've still not seen Aurelian or the folks so upset with this acknowledge any problems with what he's done, or any similar indication that they've learnt from it and won't just do the same thing again. And I've seen lots of flippant dismissals of concerns about Aurelian's actions. Both those leave me unable to trust that people will take those concerns into account before acting, which, again, is why the restrictions were put in, and why they remain. If folks want to start demonstrating they do see the potential problems, and take them seriously enough that they'll fix them to other people's satisfaction rather than just their own, then I'll personally be happy to say there's no longer a problem trusting people to do binary-only uploads. But until then, as far as I'm concerned, there is. Cheers, aj
Attachment:
signature.asc
Description: Digital signature