Re: BREAKING NEWS: Debian developers aren't trusted

[Frank Küster <frank@debian.org>]

[moving this to a more appropriate list]

Anthony Towns <aj@azure.humbug.org.au> wrote:

> 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.

Anthony, IMO you miss the point.  You give fairly good reasons why the
conflict of interest might not have been a problem in this particular
case. 

But it is there, just as the conflict of interest between the DPL and
the dunc-tank project.

>> > 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.

That doesn't sound like a reason for prohibiting a particular persons
upload rights for binary-only uploads, just like a reason for
source-only uploads.

>> 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. 

I agree (and it applies to Aurélien's work as well as to some DPL's pet
projects).  

However, it is also a problem if you don't give a damn about the
problems your non-attempts (to work, or to communicate cause).

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)