Re: Thoughts on Debian quality, including automated testing

[Frank Küster <frank@debian.org>]

Benjamin Seidenberg <astronut@dlgeek.net> wrote:

> Andrew Suffield wrote:
>
>>On Fri, Dec 23, 2005 at 02:31:19PM -0500, Benjamin Seidenberg wrote:
>>
>>> 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. 

I a well-team-maintained package, the work is actually done by "the
team", and decisions are made after finding a consensus solution in the
team.

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

I don't see why you wouldn't want to talk to the list in this case.  We
don't need someone to put the blame on (we don't have and don't want any
"punishment"), rather we need someone to make the necessary changes, be
it in the package or in the minds of the people who maintain the package.

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

I really can't see the difference, neither in a team-maintained package
nor with an applicant.  In the latter case, of course the sponsor is
responsible; but even then there's not much point in talking to the
sponsor if the applicant can just search a new one.

If a package is badly maintained and you get no response, the usual
procedure is to start with NMUs and proceed with orphaning the package
(or taking over); where's the difference here between a non-responsive
single maintainer and a non-responsive team?

And in case of complaints about a package, how should someone be able to
make good decisions if he does *not* receive the messages about it on a
daily basis, but instead has to dig through them afterwards?  Well,
there might be rare cases where this is the only way to get an outside
view of some quarrel, but we already have the TC for this.

> Basically, the Responsible field would be what you suggested - a
> Debian Developer in good standing who offers accountability for the
> project. 

Ah, so we're going to have two classes of DDs:  The ones with "good
standing", and the others who are not allowed to be in the Responsible
field? 

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

Accountability?  That only makes sense if there are consequences in case
that person  does bad work.  Either a "criminal action", or some sort of
private punishment like having to pay money.  All this does not exist in
Debian, and IMO it doesn't make sense to introduce them.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer