Bug#436093: Please decide on the ownership of the developers reference
Hi, I just saw this bug report mentioned on -vote. Setting aside the brief scuffle that happened at the time this bug was filed, and in my capacity as one of the previous editors of developers-reference and several other documents, I'd like to say that the following two points: * the developer's reference is documentation common to the entire project and as such it can't really be assigned to a single maintainer * the developer's reference is a package, and as such can have a single maintainer ...don't exactly correlate to the following two: * documents that don't have a designated maintainer can become effectively unmaintained because nobody ever takes responsibility * documents that have a designated maintainer can become effectively unmaintained because that person can give up all too easily There is no straightforward way to resolve that matter, at least I haven't seen one lately... Usually what happens, in either situation really, is that someone starts contributing so much that they take things forward a lot, and during the next random period of time they are considered the leader. Then they go away for whatever reason, and after another random period of time someone else (or even the same person) repeats the process. IMO the only half-smart thing to do with this would be to make sure that the barrier of entry into maintaining a document never goes up, because that usually only ends up increasing that period of time it takes to get someone to take it next time the document becomes unmaintained. So, in that vein, tech-ctte should err on the side of caution and avoid deciding to assign maintainership of developers-reference to any single person. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
Hi, On 21/09/07 at 12:27 +0200, Raphael Hertzog wrote: Hi, On Mon, 06 Aug 2007, Raphael Hertzog wrote: I also don't want to change the working process, although I'm interested in getting back my author/editor status. Thus I suggest the following: - I'll refrain from direct commits in the future, instead I'll open bug reports with patchs - you put me back in the Uploaders, and you accept me as an editor that can apply patches from the BTS. I won't apply them before the bug is at least 2 weeks old unless you explicitely voted in favor of the patch (in the bug log). Is that OK? Andreas, you never responded to that offer. Please do. If that's fine to you, then we can close this issue and move on. I think that we should really try to solve that issue, and get developers-reference moving again. developers-reference hasn't been uploaded for more than a year, and there are quite a lot of open bugs against it. If developers-reference should stay the reference, it should really be updated... Raphael's proposal sounds sane. But, alternatively, maybe Andreas could suggest 1 or 2 DDs that he would trust to commit patches (and maybe make uploads when he is too busy)? -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Bug#436093: Please decide on the ownership of the developers reference
Hi, On Mon, 06 Aug 2007, Raphael Hertzog wrote: I also don't want to change the working process, although I'm interested in getting back my author/editor status. Thus I suggest the following: - I'll refrain from direct commits in the future, instead I'll open bug reports with patchs - you put me back in the Uploaders, and you accept me as an editor that can apply patches from the BTS. I won't apply them before the bug is at least 2 weeks old unless you explicitely voted in favor of the patch (in the bug log). Is that OK? Andreas, you never responded to that offer. Please do. If that's fine to you, then we can close this issue and move on. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#436093: Please decide on the ownership of the developers reference
On Mon, Aug 06, 2007 at 09:06:36AM +0200, Raphael Hertzog wrote: And I hope we can agree that I'm able to review myself when it comes to the PTS and to Alioth. That's not really a review then, is it? I don't think it's my place to agree or disagree with that statement, anyway; the question we've been asked to rule on is who should be the maintainer for the developer's reference. I hope that low-level questions like this can be sorted out between the two of you without needing to involve the TC; if they can't, I guess we need to take that into account, but that would be unfortunate. 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? Requiring review before commit ensures that the rate of commits does not exceed the rate at which changes can be reviewed. -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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/
Bug#436093: Please decide on the ownership of the developers reference
* Ian Jackson ([EMAIL PROTECTED]) [070805 18:27]: It seems clear to me that Andreas wants to be the primary maintainer and to reserve the authority to make changes, grant commit access, etc. Andreas: do you have any assistants/colleagues/etc. who would be willing to help you with that so that you don't become a bottleneck ? What I consider important is that someone goes through all open issues, and checks them (which doesn't always result in comments) - I think that any package just needs this kind of clean up being performed. And as I'm doing the cleanup since more than 2.5 years, I want to have a big enough influence on what I need to clean up. Currently, I have good work relationship to Wolfgang Borchert for the docbook-transition, and to two translators (even though only French is enabled currently). There are a few regular bug reporters (like Frank) who I think I trust enough for committing by themself, but this topic hasn't be raised. In case it becomes obvious I am the bottleneck for this package (which of course includes trying to get me working on obvious applicable stuff before) I'm always happy to hand over lead maintainership (which inludes in my opinion the obligation to either go through the open issues, or make sure someone else does it) to someone else - in case Marc Brockschmidt and Martin Zobel-Helas agree that I need to transfer it, I will do so even if I disagree (which is just the default for any of my Debian work - I trust both of them enough that they can together make decisions for me if necessary). (But BTW, in case I would notice someone is regularly feeding good patches to me, I think I would rather make sure that person could actually commit, and would even trying to get DSA to make the necessary group changes, and happily hand over lead maintainership.) I'd also like each of you to answer: if the TC rules in your favour, how do you plan to deal with your opponent in this dispute ? Basically, I don't see Raphael as opponent, but as having a different opinion on how the commits should be done. And I think it is important to have a decision because it avoids further grumblings, and we can work out how we can continue working on it - we need a common starting point. (In other words, if I could vote, I would vote further discussion lowest.) In case the TC decides I'm still the lead maintainer, I would like to try to find out if there is a procedure that still satisfies my quality requirements, and will allow Raphael to contribute in a way he likes. Somehow, I am currently quite annoyed (which is perhaps not best but natural), but I'm optimistic we can still work out something which is ok. (That's basically not different from any other package or area I'm responsible for.) Unfortunatly, that can't be done now, because as long as Raphael insists in having the exactly same say as I have, we won't find such a procedure (because the procedure needs to violate that wish). Another possible way for the TC to decide on this kind of question is to ask the developers to each prepare a package and then for the TC to choose between them. Do you think that would be appropriate in this case ? Would it be a fair fight ? How long would you need ? I don't think it is appropriate for a couple of reasons (besides it being a waste of time), because: 1. at the moment something is commited to CVS, the changes are already active on the website; 2. this is not a classical package - basically, it is only a large xml-file that is really relevant; 3. the next important aspects are to make the docbook transition active on the webpage, which includes writing some scripts for the website build. Actually, I think I wouldn't take part in that, but rather go away from maintaining the developers reference, and let other people do the time consuming and unpopular tasks - it is not that I have too less to do inside and outside Debian. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
On Sun, 05 Aug 2007, Ian Jackson wrote: I'd like to ask Andreas and Raphael how they each propose to handle the maintainership of this package in future. Raphael says he wants a team. Raphael: what team did you have in mind ? Who will help you ? I've not been planning a hijack of the package. I've no new team to take out of my hat. I expect Andreas to continue to work on the package, and I just would like him to accept the fact that I can also work on it as co-editor/author. For me the ideal workflow is the current one: - someone opens a bug report - a patch is written - a patch is applied (possibly reformulated) by one of the editors Editors/authors can be trusted to commit directly (either because they believe the change to be minor, or because they're sufficiently involved in the area being covered that they know the change to be good). Anyway others authors/editors will review the changes (at least skimming through the diff sent by mail). I'd also like each of you to answer: if the TC rules in your favour, how do you plan to deal with your opponent in this dispute ? I wish he will continue to work on the developers-reference. I don't even plan to take the role of lead maintainer/editor as I'll most probably stay a minor contributor (at least as long as Andy is not MIA). Another possible way for the TC to decide on this kind of question is to ask the developers to each prepare a package and then for the TC to choose between them. Do you think that would be appropriate in this case ? No. We should strive for collaboration, not for confrontation. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#436093: Please decide on the ownership of the developers reference
* Andreas Barth [Mon, 06 Aug 2007 09:16:23 +0200]: In case the TC decides I'm still the lead maintainer, I would like to try to find out if there is a procedure that still satisfies my quality requirements, and will allow Raphael to contribute in a way he likes. Somehow, I am currently quite annoyed (which is perhaps not best but natural), but I'm optimistic we can still work out something which is ok. (That's basically not different from any other package or area I'm responsible for.) I'll throw my 2¢ here: The policy you have in place is there to ensure changes get reviewed *before* being committed, partly because what gets commited gets immediately published and hence Raphael's review after commit via the PTS diff mail is not optimal. Parting from that, why not make the review process collaborative itself, in a way similar (if I undersand correctly) the Policy maintainers are implementing?: * You have a handful of people with vote (as opposed to commit) rights. * Patches are sent to a list for review; anybody can submit patches. * Patches get applied after they receive two positive votes (if the submitter of the patch is a voter, their vote counts). * Patches can be applied by a committer after a week with no votes. The last item is so that the development of the document can progress if there's no voters active. Which I guess can happen easily, particularly at the first stages. But it could be nice to have this happening nevertheless: it encourages peer review, but without making it a bottleneck, and all commiters have to go through the same process to get their changes applied. You'd need to find some more voters, though. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Enrique Bunbury - El club de los imposibles
Bug#436093: Please decide on the ownership of the developers reference
On Mon, 06 Aug 2007, Adeodato Simó wrote: I'll throw my 2¢ here: The policy you have in place is there to ensure changes get reviewed *before* being committed, partly because what gets commited gets immediately published and hence Raphael's review after commit via the PTS diff mail is not optimal. Parting from that, why not make the review process collaborative itself, in a way similar (if I undersand correctly) the Policy maintainers are implementing?: [details skipped] I'd be fine with that. Another solution that I proposed was to use a tag to mark the version that ought to be published. That way we can commit and review in the CVS directly, and we can update the tag only when all parties are satisfied. http://www.debian.org/doc/cvs.fr.html#updates It should be a matter of doing a cvs update -r tag in the developers-reference checkout used to build the website. The sticky tag should ensure that further cvs update will follow that tag. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#436093: Please decide on the ownership of the developers reference
* Martin Zobel-Helas ([EMAIL PROTECTED]) [070806 11:42]: Hi, On Mon Aug 06, 2007 at 09:16:23 +0200, Andreas Barth wrote: 1. at the moment something is commited to CVS, the changes are already active on the website; wouldn't it make sence here, to adjust the website build-process? So everytime a new package hits the ftp-archive, the website build process downloads the archive and un-ar's it? No. We want the changes to be available as soon as possible (in case they're good changes, that is of course). 3. the next important aspects are to make the docbook transition active on the webpage, which includes writing some scripts for the website build. that could be done with the same step. Oh, please not. Well, if you want to take over lead maintainership, just do it. Otherwise, let me do it the way I consider best. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
Hi, On Mon Aug 06, 2007 at 09:16:23 +0200, Andreas Barth wrote: 1. at the moment something is commited to CVS, the changes are already active on the website; wouldn't it make sence here, to adjust the website build-process? So everytime a new package hits the ftp-archive, the website build process downloads the archive and un-ar's it? 3. the next important aspects are to make the docbook transition active on the webpage, which includes writing some scripts for the website build. that could be done with the same step. 2. this is not a classical package - basically, it is only a large xml-file that is really relevant; Is there any way to change that from ONE big file to some smaller files? That would make working as a team much less painful. (I didn't check the package and my knowledge to docbook isn't that good, so please ignore this if it is not possible.) Greetings Martin -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
Actually, I think all these solutions have the same issue: There used to be a working process for the developers reference. Than someone came, tried to hijack it and now forces me to adjust my process on the fly, while threading me to ignore me in future again. That is something I'm not going to accept. This is really driving me so unhappy and frustrated that I consider currently to drastically reduce my involvment in Debian, because it just annoys me totally. Of course, in the general case, if someone approaches me and asks me how he could contribute to an area I'm responsible for (whether that is the developers reference, or any other debian package, or anything else), I'm always interessted in finding a good working way for all people involved. But that only works if the person interested in joining shows a minimal respect for the work of the lead maintainer, and that person's style of work. (Of course, the same is true if I join another team - I don't start by telling everybody that they have to use my way of working.) I am interessted in finding a way how other interessted people could prepare changes in a way closer to the VCS used. However, we are speaking of a document which had a working process until 48 hours ago, until someone just came and committed once again, even though I asked quite often please do not. So I propose to first fix that status back to the working one, and then start (and then it is off-topic for the tech ctte) to find a good way how everyone involved can work on it. But please do not start with destroying a working way first. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
* Andreas Barth [Mon, 06 Aug 2007 12:08:45 +0200]: Actually, I think all these solutions have the same issue: There used to be a working process for the developers reference. My prior message was a direct reply (and included it, quoted) to the part where you said: In case the TC decides I'm still the lead maintainer, I would like to try to find out if there is a procedure that still satisfies my quality requirements, and will allow Raphael to contribute in a way he likes. With such a statement, I interpret that a suggestion of such possible prodecure is not inappropriate. In other words: it was not a suggestion about how to resolve this conflict, but a mere suggestion after reading you'd be interested in maybe changing the workflow one the TC resolves (if necessary) abou this. It wasn't meant as an intent to impose anything, sorry if it contributed to your frustration but it wasn't the intention. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Dido - Here With Me
Bug#436093: Please decide on the ownership of the developers reference
On Mon, 06 Aug 2007, Andreas Barth wrote: Actually, I think all these solutions have the same issue: There used to be a working process for the developers reference. Then someone came, tried to hijack it and now forces me to adjust my process on the fly, while threatening me to ignore me in future again. I've said things because I was angry. Please forgive me for that. I certainly won't ignore you, otherwise I wouldn't participate in the discussion and wouldn't try to make proposals that suit everybody. I also don't want to change the working process, although I'm interested in getting back my author/editor status. Thus I suggest the following: - I'll refrain from direct commits in the future, instead I'll open bug reports with patchs - you put me back in the Uploaders, and you accept me as an editor that can apply patches from the BTS. I won't apply them before the bug is at least 2 weeks old unless you explicitely voted in favor of the patch (in the bug log). Is that OK? That is something I'm not going to accept. This is really driving me so unhappy and frustrated that I consider currently to drastically reduce my involvment in Debian, because it just annoys me totally. Please don't do so. involved. But that only works if the person interested in joining shows a minimal respect for the work of the lead maintainer, and that person's style of work. Be sure that I respect all the work you did. Please also respect mine even if it dates back to a long time ago. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#436093: Please decide on the ownership of the developers reference
On Mon, 6 Aug 2007 09:16:23 +0200, Andreas Barth [EMAIL PROTECTED] said: In case the TC decides I'm still the lead maintainer, I would like to try to find out if there is a procedure that still satisfies my quality requirements, and will allow Raphael to contribute in a way he likes. Somehow, I am currently quite annoyed (which is perhaps not best but natural), but I'm optimistic we can still work out something which is ok. (That's basically not different from any other package or area I'm responsible for.) Unfortunatly, that can't be done now, because as long as Raphael insists in having the exactly same say as I have, we won't find such a procedure (because the procedure needs to violate that wish). You might consider setting up individual branches, and a release branch; people commit to their own branch, solicit comments, and when the review is done, those changes can be pulled into the release branch. This is the way that the linux kernel works, and is also the way that policy is set up; and using git/arch/bzr/mercurial instead of CVS would also help. manoj -- In general, they do what you want, unless you want consistency. Larry Wall in the perl man page Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
Package: tech-ctte Hi, I started to take care of the developers reference in September 2004, and have committed changes and uploaded the package regularly since then, please see http://cvs.debian.org/ddp/manuals.sgml/developers-reference/debian/changelog?rev=1.251root=debian-docview=log I asked other people to not commit directly to the cvs, but to send patches in to allow other people to review their proposal, so that we end in high quality. However, Raphael Hertzog decided to ignore this request, and continues to commit changes directly, and now even hijacked the package by adding himself as uploader without even considering to speak with me beforehand. So I want to have a decision based on 6.1.2 of the constitution whether I'm currently the lead maintainer of the developers reference or not. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
On Sun, Aug 05, 2007, Andreas Barth wrote: I started to take care of the developers reference in September 2004, and have committed changes and uploaded the package regularly since then, please see http://cvs.debian.org/ddp/manuals.sgml/developers-reference/debian/changelog?rev=1.251root=debian-docview=log I asked other people to not commit directly to the cvs, but to send patches in to allow other people to review their proposal, so that we end in high quality. However, Raphael Hertzog decided to ignore this request, and continues to commit changes directly, and now even hijacked the package by adding himself as uploader without even considering to speak with me beforehand. So I want to have a decision based on 6.1.2 of the constitution whether I'm currently the lead maintainer of the developers reference or not. Could we try to first exhaust other means of consensus reaching before summoning the tech-ctte with this? You know I am uncomfortable with the concept of package ownership, and the devref is no exception. I therefore suggest that you split the two issues at hands here, which are: 1. Raphaël committing changes directly to the CVS 2. Raphaël adding himself to the Uploaders: field About [1], directly committing changes seems the most reasonable way to manage such a project. Everything can be discussed and reverted as if it was first sent to a mailing-list. The difference is dynamism: if one assumes that the average contribution is positive, the repository is constantly and sooner in a better state. You always end in high quality anyway, since it is the uploads that determine the state of the devref, not the repository. If there are issues with the quality of a user's contribution, then this is a problem for the whole team and should be discussed within the team. It is not a problem of leadership IMHO. 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). Regards, -- Sam.
Bug#436093: Please decide on the ownership of the developers reference
* Sam Hocevar ([EMAIL PROTECTED]) [070805 14:09]: Could we try to first exhaust other means of consensus reaching before summoning the tech-ctte with this? I tried. Raphael told me: 13:00 buxy sorry, you have no ownership on that package 13:00 aba I disagree. 13:00 aba and that is documented. So, we need a decision on that. Raphael has more than once ignored requests I asked for the developers reference. This is not the way to go, at least not as long as I feel responsible for that document. 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. 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. I'm always happy to accept and add more/new contributors, as you know. However, that doesn't work with just committing though I ask not to. It rather works (like always) that people start with patches, until the lead maintainer one day says oh yes, please just commit. If people are not going to accept this way of being added to an activly maintained part of Debian, that's called hijacking. And there is no way in discussing around it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
Hi dear tech-ctte,
I'm sorry Andreas decided to escalate this so quickly instead of trying
to get things solved smoothly. However since he decided so, let me reply
and give my point of view.
On Sun, 05 Aug 2007, Andreas Barth wrote:
I started to take care of the developers reference in September 2004,
and have committed changes and uploaded the package regularly since
then, please see
http://cvs.debian.org/ddp/manuals.sgml/developers-reference/debian/changelog?rev=1.251root=debian-docview=log
I'm glad Andreas decided to take care of the document as it definitely
needed someone. However in that process he also removed all previous
contributors from any official role without consulting anyone (at least
not me). Here's the commit where he removes me from the Uploaders:
http://cvs.debian.org/ddp/manuals.sgml/developers-reference/debian/control?root=debian-docr1=1.23r2=1.24diff_format=h
So with a simple CVS commit with a log tweaked and he took over the
ownership of the document... at that time I wasn't following closely and
didn't notice the change until way after. Once I discovered the change, I
didn't say anything. The document had always been collaboratively
maintained and I never expected any trouble for me if I decided to invest
again some time in this document.
For reference (ignoring my commits of yesterday), here are the number of
lines that each person checked in:
$ cvs annotate -D 2 days ago 1.246 developers-reference.sgml | awk '{print
$2}' | sort| uniq -c
Annotations for developers-reference.sgml
***
2169 (aba
6 (ahulin
1911 (aph
483 (hertzog
1506 (joy
3 (jseidel
88 (mdz
4 (osamu
I've been very active working on this document a few years ago (2002-2003) and
despite the updates, the fixes and the rewrites, I am still the direct author of
a sizable chunk of the document.
I already wanted to commit something sometime last year and aba asked me not to
because he was in the process of converting the document to docbook. Thus I
refrained. Yesterday I had some documentation fixes concerning the PTS and
Alioth that I wanted to checking and took the opportunity to also do some other
fixes/updates.
Note that most of the current work is to apply patches sent by others, so while
Andreas owns 2169 lines according ot the stats above, a fair number have been
written by others.
I informed Andreas on IRC of my commits and he got completely mad at me because
he apparently wants control over everything happening to this document as he
states:
I asked other people to not commit directly to the cvs, but to send
patches in to allow other people to review their proposal, so that we
end in high quality.
I replied to him that the purpose of a VCS was precisely to be able to
review what others are doing and that I'll gladly discuss with him any
of my commits when he has concerns. The burden to go through a patch
and waiting that someone else applies it is not worth it in that case.
In particular when I am one of the co-authors!
BTW I'm French, Andreas is German, none of us are native english speaker.
So as far as quality goes, I suppose he speaks of content rather than
formulation. And here I have a problem with him having full control over
the content.
This is not a package of third-party software. It's a basic Debian document
that has always been co-authored by Debian developers. I want this to remain
that way and I refuse any take over by a single person. I had no problems
with Adam Di Carlo (the original author) having dictatorial control on the
package, but I have one when Andreas wants that same control while the package
is supposedly co-maintained by the debian-doc group.
I'm happy to let Andreas check in any changes as he see fit, but I want him
to accept that the same goes for me (and as far as I'm concerned with any other
member of the cvs_doc Unix group that cares about this document).
However, Raphael Hertzog decided to ignore this request, and continues
to commit changes directly, and now even hijacked the package by adding
himself as uploader without even considering to speak with me beforehand.
I didn't remove you from the Uploaders field. I just added myself back.
And if someone hijacked the package in the first place, it's you.
So, to sum up, I ask the tech-ctte to rule in favor of co-maintenance of the
package, exactly like it has always been done with this package in the
pre-aba times.
Regards,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#436093: Please decide on the ownership of the developers reference
On Sun, 05 Aug 2007, Andreas Barth wrote: * Sam Hocevar ([EMAIL PROTECTED]) [070805 14:09]: Could we try to first exhaust other means of consensus reaching before summoning the tech-ctte with this? I tried. Raphael told me: Let me insert the start of the discussion: buxy FYI, I've been working on developers-reference this afternoon, I did several commits in case you don't receive them via the PTS like I do aba that was a *very* bad idea, as we already converted the developers reference to another format. buxy why isn't it in the repository? it's been more than a year since you last told me to stop committing because you were in the process of converting it aba perhaps you should just follow the discussion on -doc. and I asked you to not commit stuff just so, because I'm taking care of it. I would *really* like you to stop committing stuff. 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-docr1=1.23r2=1.24diff_format=h In the whole IRC discussion I tried to ask him to point me to whatever changes were pending and what problems he had. I offered him to redo my work of yesterday on his pending version, but instead of discussing that, he went on that issue of ownership and stopped discussing to open that tech-ctte bug report. 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'. 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'm sorry but the place to discuss that conversion has always been the following bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374220 There has been no messages since June 2006. And he committed lots of stuff in the mean time. So I assumed it was ok to work on the document. I have always been subscribed to the PTS of developers-reference including CVS commit notices and always followed its evolution through the years since 2002. End of discussion for me. I'll reply to any questions from the tech-ctte however. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#436093: Please decide on the ownership of the developers reference
* Raphael Hertzog ([EMAIL PROTECTED]) [070805 14:52]: I'm sorry Andreas decided to escalate this so quickly instead of trying to get things solved smoothly. This wasn't quickly. You said sure feel free to ask [the tech ctte]. So, I read that as go ahead - and BTW, we need a decision on who is the maintainer. You said more than once to me that you're not going to accept me as the lead maintainer. And this is one of the cases where I believe a decision helps to avoid further anger, because than we both know what the situation is. I'm glad Andreas decided to take care of the document as it definitely needed someone. However in that process he also removed all previous contributors from any official role without consulting anyone (at least not me). Here's the commit where he removes me from the Uploaders: http://cvs.debian.org/ddp/manuals.sgml/developers-reference/debian/control?root=debian-docr1=1.23r2=1.24diff_format=h That's now 2.5 years ago or so - at that time, I discussed it with the people who were doing lots of QA (I'm not sure how good it is documented), and they told me that the developers reference could be basically seen as orphaned. You were at that time quite inactive, BTW. I'm not arguing that the commit message was the best one I ever used. Once I discovered the change, I didn't say anything. So, you accepted that I became the lead maintainer of this document. Good. The document had always been collaboratively maintained and I never expected any trouble for me if I decided to invest again some time in this document. I'm not against other people becoming more active. Please read the README-contrib - it tells: | Do not commit patches to the developers reference yourself unless | authorized to do so. Patches need to be finalized and common opinion | before they are applied. This is even true if you happen to have | cvs access for other reasons. I don't understand why you just don't write mail before, or speak with me, but just go ahead committing even though I ask you not to. You are not accepting that I currently have the main authority on the developers reference, that is the core of the problem. I've been very active working on this document a few years ago (2002-2003) and despite the updates, the fixes and the rewrites, I am still the direct author of a sizable chunk of the document. I'm not argueing to keep you out. But even as a former main author, you should (even if only for politness!) ask the current main author and maintainer before committing patches - especially as this has been explicitly requested more than once. BTW I'm French, Andreas is German, none of us are native english speaker. So as far as quality goes, I suppose he speaks of content rather than formulation. Oh, I usually ask good english speakers for proofereading if I have doubts. Even that I'm not a native english speaker doesn't mean I'm unable to commit high quality english texts. :)) (I used Frans quite often for that, or other people I know well.) And here I have a problem with him having full control over the content. I don't consider that the Developers Reference should have *my* opinion, but the opinion of Debian at Large, even if I disagree with that. I see it as part of my job to give other people enough review chances to make sure the Developers Reference matches Debian at Large. If you have problems with my way - ok, we can speak about it. But you cannot just hijack the Reference because you disagree with my way. So, to sum up, I ask the tech-ctte to rule in favor of co-maintenance of the package, exactly like it has always been done with this package in the pre-aba times. You mean like prior to 2.5 years ago, where nobody felt responsible, and there was noone going through the bugs, and checking for a basic quality of that document? As said, as lead maintainer I'm happy accepting contributions from other people, and if I have seen that these contributions are of good quality, I'm happy to ask people to commit themself - people know I'm quite open to that (and/or even handing over lead maintainership to someone else one day, if someone has more time and energy for that than I have). But not by hijacking. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
* Raphael Hertzog ([EMAIL PROTECTED]) [070805 15:12]: In the whole IRC discussion I tried to ask him to point me to whatever changes were pending and what problems he had. I offered him to redo my work of yesterday on his pending version, but instead of discussing that, he went on that issue of ownership and stopped discussing to open that tech-ctte bug report. Sorry Raphael, that is just throwing sand in our eyes. You have more than once declared you're not accepting me as main authority on the developers reference, and this has now be to cleared. The good thing is that the constitution gives us a clear process how this can and should happen. As the results are, I'm now demotivated enough to stop any further Debian work at least for today. There has been no messages since June 2006. And he committed lots of The bug unfortunatly doesn't have the final status. There was some discussion on and after this years Debconf. If you would have asked, you would have known. (And I'm not the main driving force on that change, btw.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
Hi, I am not sure that this is something that ought to be in the tech-ctte's jurisdiction; this seems a social problem, not a technical one, and thus is not something I think the tech ctte is competent to address (even though the constitution does explicitly mention this as a case of the tech ctte's powers). I would strongly urge all parties to try all possible means of rapprochement before escalating to the ctte (indeed, I think this is the type of issue that should go to the nascent social committee proposal currently under discussion). manoj -- Guard against physical unruliness. Be restrained in body. Abandoning physical wrong doing, lead a life of physical well doing. 231 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
Manoj Srivastava writes (Bug#436093: Please decide on the ownership of the developers reference): I am not sure that this is something that ought to be in the tech-ctte's jurisdiction; this seems a social problem, not a technical one, and thus is not something I think the tech ctte is competent to address (even though the constitution does explicitly mention this as a case of the tech ctte's powers). I would strongly urge all parties to try all possible means of rapprochement before escalating to the ctte (indeed, I think this is the type of issue that should go to the nascent social committee proposal currently under discussion). The constitution says that it's within our power and we should follow the process and appeal mechanism we currently have for resolving this issue, even if we think it should be dealt with by some as-yet-unformed body in the future. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
So as I understand it: * Andreas argues that he became the lead/sole maintainer with his commit of 2005-02-02 and that he is therefore the current maintainer. * Raphael argues that that commit isn't definitive and that we should regard Raphael and Andreas as co-maintainers. ? This is relevant for deciding what the status quo is but not for any other purpose AIUI. The TC will probably tend towards the status quo by default, but it's certainly not definitive. I'd like to ask Andreas and Raphael how they each propose to handle the maintainership of this package in future. It seems clear to me that Andreas wants to be the primary maintainer and to reserve the authority to make changes, grant commit access, etc. Andreas: do you have any assistants/colleagues/etc. who would be willing to help you with that so that you don't become a bottleneck ? Raphael says he wants a team. Raphael: what team did you have in mind ? Who will help you ? I'd also like each of you to answer: if the TC rules in your favour, how do you plan to deal with your opponent in this dispute ? Another possible way for the TC to decide on this kind of question is to ask the developers to each prepare a package and then for the TC to choose between them. Do you think that would be appropriate in this case ? Would it be a fair fight ? How long would you need ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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-docr1=1.23r2=1.24diff_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/
Bug#436093: Please decide on the ownership of the developers reference
On Sun, 5 Aug 2007 17:24:02 +0100, Ian Jackson [EMAIL PROTECTED] said: So as I understand it: * Andreas argues that he became the lead/sole maintainer with his commit of 2005-02-02 and that he is therefore the current maintainer. * Raphael argues that that commit isn't definitive and that we should regard Raphael and Andreas as co-maintainers. ? This is relevant for deciding what the status quo is but not for any other purpose AIUI. The TC will probably tend towards the status quo by default, but it's certainly not definitive. I'd like to ask Andreas and Raphael how they each propose to handle the maintainership of this package in future. It seems clear to me that Andreas wants to be the primary maintainer and to reserve the authority to make changes, grant commit access, etc. Andreas: do you have any assistants/colleagues/etc. who would be willing to help you with that so that you don't become a bottleneck ? Raphael says he wants a team. Raphael: what team did you have in mind ? Who will help you ? If I recall correctly, the package started out as a team maintained one. I seem to recall having commit access at some point, though I certainly did not make use of it. So perhaps the original team could be candidates for the new team (provided, of course, they are interested -- though it is possible that some, like me, are no longer interested in the package) I'd also like each of you to answer: if the TC rules in your favour, how do you plan to deal with your opponent in this dispute ? Another possible way for the TC to decide on this kind of question is to ask the developers to each prepare a package and then for the TC to choose between them. Do you think that would be appropriate in this case ? Would it be a fair fight ? How long would you need ? manoj -- Intolerance is the last defense of the insecure. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
