Re: Thoughts on Debian quality, including automated testing

[Benjamin Seidenberg]

Andrew Suffield wrote:

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, they

both deserve the credit

I 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).

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.

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.

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.

Benjamin

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.

signature.asc
Description: OpenPGP digital signature