I hope that some resolution is possible here without having to take this all the way to a TC vote. Having to pick a maintainer for a package in the case of disputes is certainly one of the responsibilities of the TC, but it's one that I'm loathe for us to use because it's near impossible to exercise that power without one of the parties coming out the "loser", in a much greater sense than when adjudicating a specific technical point.
I have a good deal of respect for both of you as long-time contributors to Debian; I hope you each manage to remember the contributions of the other as well during this discussion, and not let recent conflicts dominate your relationship with one another. On Sun, Aug 05, 2007 at 03:08:02PM +0200, Raphael Hertzog wrote: > > 13:00 <buxy> sorry, you have no ownership on that package > > 13:00 <aba> I disagree. > > 13:00 <aba> and that is documented. > <buxy> you removed me without asking > <aba> I didn't remove you. > <buxy> > http://cvs.debian.org/ddp/manuals.sgml/developers-reference/debian/control?root=debian-doc&r1=1.23&r2=1.24&diff_format=h 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, and did you try at the time to contact the people that were listed as Uploaders?) > > > As for Raphaël adding himself to the Uploaders: field, I have no > > > particular opinion about it. I suggest discussing it within the team, > > > too, and either reverting the change, or reaching a common agreement > > > about upload rules (which I would obviously prefer). > > The "team" currently consists of me. > That's not what the "Maintainer" field says. And the unix group associated > is 'cvs_doc'. Raphaël, surely you're aware that there are many packages which give mailing lists as the maintainer, without implying that everyone subscribed to that mailing list is implicitly part of the "team"? (Moreover, haven't you said that you aren't/weren't subscribed to -doc, which implies that if the Maintainer field determines who the team is, you're not part of it anyway?) Adding oneself to the Uploaders field of a package without discussing with the current Uploaders/Maintainer is, IMHO, always bad form. I maintain that *hijacking* packages is better than this, because at least when hijacking, you're not asserting the existence of team maintenance where no team exists. Summing the above two points together, I would argue that neither of you are clearly in the right; I hope that you can both agree with this, and that therefore neither of you should be treating the package as "yours". 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. > > All the uploads and changes in the last 2.5 years were done by me > > (except for the french translation of course, whereas I'm in good > > contact with the appropriate translator). I picked up the package after > > a long periode of inactivity, dusted off some old bug reports, added > > lots of stuff etc. > Of course, he forbid anyone else with commit rights to commit directly. > So it's quite logic that he was alone in applying patches. I respected > his wish once because he gave a good technical reason. Now one more year > elapsed and he again gave me the same reason: the conversion to docbook > XML is pending. 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. 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. Raphaël, it would be nice if you would give him this same benefit of the doubt. -- 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/