Re: [Fink-devel] Re: FYI: SDL change

[Trevor H. <tr...@vo...>]

On Mar 19, 2006, at 1:04 PM, Benjamin Reed wrote:

> As far as maintainership being in perpetuity, it makes sense to me
> because generally the maintainer, in the course of packaging  
> something,
> is most likely to understand issues in new releases of the  
> software, is
> most 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 makes
> sense to, by default, defer to the person who understands that  
> software
> well 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