Andrew Suffield wrote:
Fair enough. The reason I think of maintainer as this is that it's the most often seen item associating the package with a person. Example being apt-cache show, the front-ends, the bts, etc.On Fri, Dec 23, 2005 at 02:31:19PM -0500, Benjamin Seidenberg wrote:Andrew Suffield wrote:On the other hand, I think there might be some benefit to requiring that the Maintainer field must always denote one single Debian developer, who would be the "buck stops here" guy for that package. Not an applicant, not a mailing list, and not a group of people. I believe the tools have now advanced to the point where this is a practical option. In general you're always far better off forcing every *change* to a given component to go through a single individual. Large projects need a pumpking, because dogpiling creates lousy software. For Debian this would be cumbersome and unwieldy as a rule, but some high-importance tasks could benefit from it.I think you have something here, but I think allowing an applicant/mailing list in maintainer should be ok.In the case of an applicant, if they're doine the work, theyboth deserve the creditI don't think we should be using the control file for this purpose. Particularly since it does not and never has included a list of the people who do most of the work on a given package. Consider samba - the 'maintainer' hasn't been heard from in ages, and nowhere in the control file are all the relevant people listed. The obvious place for this information would be the changelog - this is the current convention (again, see samba).
The difference is who does the work. The Responsible field would be the one to talk to if the package does something bad from the project's perspective such as a deliberate security issue or it not being up to snuff. They would also be the one to talk to if the maintainer or team doesn't respond to other complaints. The maintainer would be the one that users look to on a daily basis - manages bugs, does most of the work, etc.and should be the one to get all the messages that the various debian infrastructures sends out (Archive scripts, BTS, point of contact for security, etc).I *think* that the relevant infrastructure tools have now all been fixed so that you don't have to use the Maintainer field to accomplish this.Instead, why not propose a Responsible-For: header for control that lists a person inside the project who the buck stops with in the case of an applicant or team maintained package?Because I don't see how it would be semantically different to the Maintainer field. The distinction between them is not apparent (what is Maintainer supposed to mean under this scheme?). And adding new fields is more work, so you don't do it without a good reason.
Basically, the Responsible field would be what you suggested - a Debian Developer in good standing who offers accountability for the project. The Maintainer would be the person or team doing the work, possibly a mailing list or someone who is not a DD. The key is that the Responsible-Person field would add accountability.
Benjamin
Attachment:
signature.asc
Description: OpenPGP digital signature