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

Re: Thoughts on Debian quality, including automated testing

Frank Küster wrote:

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

Right. That was the biggest problem I had with Andrew's idea, he wanted to use the maintainer field for one person and only one person, who was a DD. As an applicant, I didn't particularly care for this, and suggested a "lesser-of-two-evils" approach.

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.

*shrug* I agree. At least in my suggestion, you still have the maintainer field, as opposed to it being a single DD in Andrew's proposal.

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?

Again, it was my way of tempering Andrew's proposal.

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.
That was one of my points, under Andrew's proposal, the maintainer would become a DD and the team/applicant wouldn't recieve these emails.

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

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
I would assume all DD's are members in good standing of the project, if not, shouldn't they be kicked out?

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
Again, this is partly a response to Andrew's proposal of only allowing a DD as a maintainer and having them as the person where "the buck stops here". The accountability he wants is the one refered to here.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: