[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)
