On Mar 19, 2006, at 1:04 PM, Benjamin Reed wrote:
As far as maintainership being in perpetuity, it makes sense to mebecause generally the maintainer, in the course of packaging something, is most likely to understand issues in new releases of the software, ismost likely to be able to get upstream to listen when patches are required, etc. They become the "subject matter expert" in business terms, through the act of packaging it in the first place.
For large complex packages, I agree. But most packages are small enough that all of this expert knowledge is expressed in the .info file. The arcane magic gets transferred to the fields themselves: the tricks about compiling and installing the package, any patches that need to be applied for unusual problems, etc. And if that's not enough, there are always the Desc* fields. There's usually no reason for special knowledge about a package to be locked up in the mind of a subject matter expert.
But of course, I said "usually." No one approach best fits all package types, so how about a "Lead-Maintainer" field? If specified, this is the person who must approve all changes in new versions. Otherwise, any person can submit a new version to the tracker for approval, with the understanding that he must be responsible for fixing any breakage in that new version.
It makessense to, by default, defer to the person who understands that softwarewell enough to package it, when questions arise.
But this can still be the default in the model I propose. And as you said in your response to Max, sometimes changes are so trivial that there's no need to defer to the original maintainer. It would be nice to have a sort of wiki-like model for editing package descriptions.
Trevor
smime.p7s
Description: S/MIME cryptographic signature
