Hi Charles, On 12-05-31 at 08:29am, Charles Plessy wrote: > Le Wed, May 30, 2012 at 11:11:51AM +0200, Jonas Smedegaard a écrit : > > > > *nothing* qualifies for a hijacking. > > Dear Jonas, > > your reaction seems to imply that hijacking is an implicit statement > of failure. But this can be dis-ambiguated by thanking the maintainer > for his past work, bringing the package in a team where everybody is > welcome, which is not the same as moving it between two single > maintainers, and by underlining that the reason for transferring the > package to a team is that the mainainer, while not on vacation, could > not be contacted. No, my point is not about lack of recognition for past contributions. No, it is not about teams being welcoming or superior in others ways. It is about Debian not being the Wild West. I distinguish between "hijacking" and "friendly takeover" and "project overruling". What you describe is the proper way of a friendly takeover: You agree with the former maintainer to take over, and in the changelog entry formally announcing it you thank the former maintainer for the past efforts. It can be a person or a team taking over, and if the team also includes the former maintainer it might make sense to skip the "thank you" part. "project overruling" is when Debian by its defined procedures judge that the maintainer is unfit to maintain, and therefore relieve her/him/them of her/his/their duties, Hijacking, in my vocabulary, is when a non-maintainer takes matters in his/her/their own hands and takes over maintainership without the consent of the former maintainer and outside formal Debian procedures. > There is indeed a problem with packages not maintained by DDs as they > can not formally declare themselves on vacation, but search engines > would be able to find such a statement on mailing lists if it had been > posted. My non-Debian-member-as-maintainer rant is not about vacation notices, but about bonding and commitment. It's somewhat like making a baby versus having a baby: Making a Debian package requires certain skills, and some work once (for an hour or a year, depending on who you are). We dearly encourage anyone interested to try it out, and share with the results with us and the rest of the World. Having a package (a.k.a. being a Debian maintainer) additionally requires passion and devotion for a looong time - ideally for the full lifetime of the package. I don't mean to say that only the Debian elite should raise babies, others should use protection - that Debian members are better parents. My point is that the social structures of Debian matters for the quality of maintainance: When you do a poor job in Debian, you get remarks by your peers about it. When you do a poor job outside of Debian, there is silence. Your bonding with Debian helps you either care more or pass it on to someone who cares or get rid of the package. Debian should avoid elitism by welcoming newcomers to our village, not by encouraging raising kids in the jungle. > I think that it is important to have the flexibility to transfer a > package for which the maintainer is not responding, in a neutral way > that is not making any judgement on why he is not responding. I interpret "neutral way" as "through defined process" (i.e. our MIA process or the technical committee) rather than ad hoc. I disagree that we need a defined process for "not responding" regarding a single package as opposed to our "missing in action" affecting all packages a maintainer is involved in: I believe there is no common pattern for the special cases of a maintainer being active but irresponsible towards a subset of packages. MIA process should not be nosy: We should not care _why_, only _if_ a maintainer is not doing the job responsibly. I am unaware if current process is too nosy - but if so it seems ripe for improvements. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: Digital signature