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

Re: BREAKING NEWS: Debian developers aren't trusted

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.


Attachment: signature.asc
Description: Digital signature

Reply to: