Bug#436093: Please decide on the "ownership" of the developers reference
Hi,
On Sun, 05 Aug 2007, Steve Langasek wrote:
> 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.
Sure.
> > > 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?)
Sure. Note however that I always followed the package through the PTS and
it has always been enough to be able to contribute (in particular to
review changes committed by others).
I used to be subscribed to -doc, but most the messages were uninteresting for
me as I don't have a general interest in all the documentation but only in
this document.
> 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".
I accept my part of the blame. My behaviour has not been perfect but Andreas
hasn't been much "welcoming".
> 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.
100% agreed.
> > 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.
Sure. But I never intended to commit non-consensual stuff without review.
If you look at my changes, you'll find trivial fixes and updates
concerning the PTS and Alioth (both are parts of the document that I
initially authored anyway).
And I hope we can agree that I'm able to review myself when it comes to
the PTS and to Alioth.
> 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.
I don't follow your reasoning, in what way the fact to not commit helps
for the review?
> 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.
I can try.
It all boils down to a problem of trust. I trust Andy but he doesn't seem
to trust me.
He's behaving as if I had to make my proof as an author/editor of that
document and I don't think that I deserve this treatment when I've been a
former contributor.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: