On Mar 19, 2006, at 11:58 AM, Max Horn wrote:
However, for those package maintainer who *are* willing to quickly react on such notifications (e.g. me), it is a bit hard to accept that their packages are simply taken out of their hands :-/.
I believe these problems exist because it's not clearly defined what the "maintainer" field really means. I don't think it's even mentioned as an aside in the Fink packaging tutorial and manual. The protocol of package maintenance is thus left to the reader's assumptions.
Let me give you an example of what I mean. When I first began writing packages, my assumption was that the maintainer designation was limited, that it only went as far as the corresponding version number of a given .info file. I figured any bug reports for that version would go to the maintainer, but if someone wanted to release a new version (that is, upstream version, not package revision), then he could simply "fork" the .info file and replace the old maintainer's name with his, then submit it to the tracker for review. That made sense, I thought, because new versions could be released more frequently. There would be no bottleneck of a single maintainer. Furthermore, any bug reports caused by changes in the new version would go to the new version's maintainer, not the old one. (That solves the problem you mentioned of receiving bug reports for changes you never made.)
I realize now that the maintainer field is not like this. Instead, it seems that the maintainer designation is "in perpetuity". Whoever submits the first .info for a package becomes "maintainer for life" and is the sole dictator of all future changes to that package. At least, that's my understanding of how it's supposed to work. Personally, I don't think it's the right way to do it. I don't see the point of packages being forever "owned" by one person. And though I understand that you feel snubbed at having your package "taken out of your hands," I feel that packages *should* be able to be taken out of a maintainer's hands, as long as responsibility for the changes are also taken out of the maintainer's hands.
But regardless of what I think, Fink's policy should be followed, good or bad. On the other hand, it's difficult to follow a policy that isn't written down somewhere. That's probably why you're having the problems you spoke of. Most people have the best intentions -- they don't mean to ignore your role as maintainer -- they just don't know what the real protocol is. It needs to be clearly stated somewhere.
Trevor
smime.p7s
Description: S/MIME cryptographic signature
