Frank Küster wrote:
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.Benjamin Seidenberg <astronut@dlgeek.net> wrote:Andrew Suffield wrote:The difference is who does the work.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.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.
*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.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 notbeing 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?
Again, it was my way of tempering Andrew's proposal.
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.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.
I would assume all DD's are members in good standing of the project, if not, shouldn't they be kicked out?Basically, the Responsible field would be what you suggested - a Debian Developer in good standing who offers accountability for theproject.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 Responsiblefield?
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.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
Cheers, Benjamin
Attachment:
signature.asc
Description: OpenPGP digital signature