Steve Langasek <vorlon@debian.org> writes: > On Mon, Jul 30, 2007 at 10:36:46AM +0200, Marc 'HE' Brockschmidt wrote: >> ... without ever *asking* if that would be true. I assumed this idea to >> be dead because last year's discussion on -newmaint showed that most DDs >> were against that proposal. > Surely, "discussion on -newmaint" and "most DDs" are contradictory? :) I think it was crossposted to -project. At least a lot of non-NM people were part of the discussion. >> (i) You have added a policy for everything, but removal from the DM list >> is still under-defined. This is a crappy idea. Imagine a Sven Luther >> case in DM - someone who's technically capable and invests a lot of >> time, but leads to regular flamewars. There is no question that >> we would need to have some procedure to decide what should happen >> in such cases. > Are you aware that one of the "crimes" Sven says Debian has committed > against him is that the DAMs didn't follow their own procedure for expelling > developers? Yes. > I think it's rather silly to accuse the DAMs of wrongdoing given that > the procedure in question was the documented procedure by which a > developer could *request* an expulsion, and this in no way binds the > DAMs to not act of their own accord as they think appropriate; but I > think it puts the lie to the claim that defining expulsion procedures > in advance is a necessary (or sufficient) safeguard against > flamewars... > >> Now, back to the Sven Luther example: Imagine how *that* flamewar >> would look if the procedure to kick him out would have been >> hand-crafted just for his case? > > I don't think that calls for much imagination at all, I think the flamewar > would looks about like the one we already had... Well, the problem with the Sven Luther example is that the procedure actually wasn't followed by the letter, but used as a, eh, "guideline". I don't think it was wrong to expelulse [1] Sven, but if you *know* that you face the danger of being accused of doing something solely for personal reasons, you should IMO try to stick to the letter of the rules. Of course, the DAMs are free to do do whatever they want with people's accounts, but starting with a procedure and ending the process by switching to one's absolute power over Debian accounts feels foul. >> So basically, I won't accept your proposal as remotely sane until >> the initial policy includes some guidelines on removals from the DM >> list. > And is that something you're interested in helping to specify? I at least want to see some rules that describe who can ask for a removal from the keyring, how that should be done and (that's the most important thing for me) how the DM keyring maintainers, a *team*, should decide what to do with the request. >> (ii) Debian has a QA problem. Sponsorship did nothing to improve it. In >> fact, I believe sponsorship to be one of the reasons for it. Let's >> explain this a bit: >> Sponsorship is one of the main factors that lead to the explosion >> of the number of packages in the archive. The growth in the number >> of packages is, in fact, much bigger than the growth in the number >> of users. This means that the number of users per package has >> fallen [2], directly translating to the fact that packages receive >> less testing before they are released. This is equivalent to bugs >> and packaging mistakes staying unnoticed for a longer time. >> This problem is almost exclusive to packages that are priority: >> optional|extra, ie packages likely to be maintained by newcomers to >> Debian. > This is a fair point, but I'm afraid that you haven't convinced me that > adopting a more lightweight process for *maintaining* those packages *after* > they've been uploaded (remembering that the proposal doesn't let DMs upload > new packages autonomously) is going to increase the QA problems over the > present case. It reduces the number of checks done on each package. The problem I see is when someone (let's say, Rperl-lover) maintains, say, some perl packages and gets his key in the DM keyring. After a year, he needs some C++ application and a library in the archive and wants to maintain it. Some developers sees Rperl-lover is already a DM, so assumes he knows what he is doing. There is a short package check, a sponsored upload to NEW with the DM-Upload-Whatever-it-was-called-field set to yes. For some reason, Joerg isn't doing an in-depth check of the package, or some other ftp-team member is working on NEW, the package goes on without much review. All in all, it's not too unlikely that this happens - and FWIW, I don't want to rely on the NEW queue for basic QA checks. Anyway, now Rperl-lover can upload the package on his own, but as a pure perl robot, he is bound to fuck up. After a year, *you* will need to kick him to understand how SONAMEs work :) My whole argument boils down to "I don't trust DDs". I would be happy to vote in favour of this proposal if the list of packages each DM can upload is controlled by a small group of people (the DM keyring maintainers) and not a group of ~1000 people. >> and there is always the simple test of taking 20 random packages from >> the archive and checking them for obvious packaging problems [4]. > Ooh. Can we set up a website to let people do that? That would be fun QA > work, and maybe a fun NM activity besides :) It shouldn't be too hard. If someone would be willing to work out some package karma based on lintian warnings, bug numbers and popcon data, we could even sort packages so that likely candidates show up on the top of such a list :) I've put it on my todo list. Marc Footnotes: [1] I believe this should be the official Debian term, BTW. -- BOFH #428: Firmware update in the coffee machine
Attachment:
pgp75WVAX8M51.pgp
Description: PGP signature