Bug#436093: Please decide on the "ownership" of the developers reference
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
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.