* Steve Langasek ([EMAIL PROTECTED]) [070805 23:49]: > Andi, this looks like a fair point to me. If we're going to treat this as a > question of who has the "right" to be maintainer of the package, then > Raphaël also has some claim that you hijacked the package first. (You > mention that you talked to "people who were doing lots of QA" -- but did you > run this by the debian-qa mailing list so that there's a public record of > the discussion and an opportunity for comments
Please remember that at that time, basically Martin was QA-in-a-person (and Jeroen and I were the both people next to him), and I for sure discussed it with both of them. I'm not sure any more about the details - that was at a time before I became a member of the release team IIRC, so you see how much more needed to fit into my brain inbetween. If I would have had my todays knowledge back in 2004, I definitly would have done things different than today, and with my todays knowledge, I would have accepted a complaint about the way I took over the package. However, on the other side, I didn't receive a single complaint (or at least none I could remember) about this until a few days ago. If someone would have asked me in late 2004/early 2005 "hey, can you please re-add me back as uploader", I would have just done it. Also, I am a strong believer in de-facto standards. I maintained the developers reference alone for more than 2.5 years, which made me the maintainer of that software. If someone doesn't speak up after hijacking for more than 1 year, I really think the hijack is ok (minus circumstances like illness etc, where someone was out-of-the-world for a long time). Of course, if someone comes back and says "I used to maintain package foo you maintain now, can I become co-maintainer", I'm usually quite open to that. If someone just uploads a package (which de-facto any commit is in the case of the developers reference), I definitly react different. >, and did you try at the time > to contact the people that were listed as Uploaders?) AFAIR I did try but not by mail. > Recent activity should generally weigh more heavily than historical > involvement when deciding who should be in charge of a package, but > particularly for a package such as this, we should surely be aiming for a > spirit of collaboration rather than territoriality. I definitly agree I'm aiming for a spirit of collaboration. All I ask is the due respect for the maintainence of the package in the last 2.5 years, and the working process for it. > I would welcome clarification from Andi on this point, but it seems to me > that the "don't commit" rule might be designed to make it possible to > establish consensus about a change *first*, before committing it to the > repository. IMHO this is not an unreasonable rule; in many cases where > review/consensus is given high importance, but the time developers have > available to them for doing such reviews is limited, this is an effective > mechanism indeed. That is all it is about. For this reasons, I normally also let bug reports stay for some time uncommited, so that anyone has due time to check and review it. > So I would give Andi the benefit of the doubt, that the "no commits without > discussion" is not intended to give him *personal* veto power over any > changes, but rather to ensure that any changes get multiple eyeballs on them > before being committed. Definitly. I don't think I have a personal veto power on content (technically spoken, the only real veto power I see on the content is by the tech ctte, though of course I would make sure content matches reality, i.e. we don't describe stuff as ok which we know the ftp-masters will reject). I just see it as "procedural veto" to make sure the content is reviewed enough. Nothing more, but also nothing less. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
