[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Thoughts on Debian quality, including automated testing



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

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

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature


Reply to: