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) 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? 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... > 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 guess I don't see this as a compelling reason to vote "further discussion", unless there is some evidence that people want to discuss it. My default assumption is that if the discussion hasn't taken place during the discussion period for the GR the first time around, it probably isn't going to happen just because the GR is voted down either. > (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. > On the other hand, sponsorship is (besides the few cases were > people only want to maintain a few packages and not invest more > time in Debian) used as an education system. It's training people > on the job, allowing them to understand policies and procedures > when bugs are reported or their sponsor notices a problem while > uploading. Nor does the existence of DM preclude the existing sponsorship system. I think it's well known that there are already sponsors today who trust their sponsees to prepare packages without review or assistance; DM would actually give the rest of the community *more* oversight of these maintainers, by allowing for any DD to identify these packages that have been uploaded without review, review them, and if necessary revoke the DM's upload privileges for that package. > 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 :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
