Re: Bug#436093: Please decide on the "ownership" of the developers reference
* Steve Langasek (vorlon@debian.org) [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/
Reply to: