The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new maintainers

On Wed, 19 Mar 1997, Susan G. Kleinmann wrote:

> Bruce said:
> > I think we need to set some guidelines for accepting new maintainers. 
> 
> I think there are probably going to be complaints about Debian becoming
> a closed distribution if the guidelines for accepting new maintainers
> aren't fairly open.
> 
> Here are some ideas:
> a) allow new maintainers to upload packages to some site or
> distribution which is labelled as 'provisional'.  Then once a month,
> or so, let the BoD vote on which of those packages constitute the
> most important additions and best packaged packages of those that had
> been uploaded.  If the BoD doesn't want to do this, then maybe some
> other body could do this.  

Non of this provides any "real" protection. Pathological personalities are
know to be very good a "appearing" normal. If I wanted to damage Debian, I
could bide my time, being patient and conservative, until I had passed my
"probationary" period. Then, once I was a "trusted" member of the group, I
would be free to deliver whatever nasties I wanted.
In this reguard, what we need is a continuous, general, practice of
"checking in" package updates. Maybe we can require that all packages be
reviewed by a second developer before they can move from "unstable" into
"stable". Thus if a particular maintainer maintains 4 packages, he/she
should be assigned 4 other packages to "verify" as part of their
responsibilities.
I don't think that putting stumbling block in front of prospective
developers is compatible with the spirit of the Debian Distribution.

> 
> b) (this won't save any time, but would limit the number of maintainers).
> If some package is found to egregiously break Debian policies then 
> an existing maintainer should lose his privileges.  Some obvious
> flaws which come to mind are: no copyright, no author, or inclusion of 
> ITAR software without notification.
> 
The problem with this is that you can't determine intent from such simple
actions. People are falible and make simple mistakes. If I forget to
include a copyright, or don't notice ITAR software in the package, I'm
simply mistaken, not malicious.

This is not a simple problem, but I don't think we can solve it with
behaviors that treat "new" maintainers as more suspect than folks already
here. Whatever practices that we institute, they must impact current
maintainers in the same fashion that they impact new folks.

Luck,

Dwarf
-- 
_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-