Re: Re-thinking Debian membership
On Fri, Oct 24, 2008 at 02:12:27PM +0200, Michael Hanke wrote:
> On Fri, Oct 24, 2008 at 01:49:48PM +0200, Patrick Schoenfeld wrote:
> > Hi,
> >
> > On Fri, Oct 24, 2008 at 01:35:43PM +0200, cobaco wrote:
> > > AIUI he's just advocating having the equivalent of a (publicly scrutinized)
> > > NMU for the keyring, that is:
> > > - have trusted gatekeeper(s) who normally does all changes
> > > - have all changes be public (many eyes make all bugs shallow)
> > > - also have the possibility for the equivalent of an NMU, for those cases
> > > where the gatekeeper is on vacation/to busy/otherwise unavailable/goes
> > > rogue.
> >
> > and where is the difference? Still, every DD would be able to kick out
> > every other DD of the keyring. Obvious the only protection against abuse
> > is that it should be public. But that does not help much. If someone
> > removes the key of somebody this causes damage, even if the most obvious
> > damage (the removal itself) can be fixed easy and quick.
>
> The keyring does not have to be exposed directly. It could work via a
> delaying queue or stanging area. Changes commited to be applied to the
> keyring could be made publicly available for peer-review. This would
> make it possible that any change could be veto'ed by any other project
> member during the delay period.
>
> If anyone's key is about to be removed from the keyring that person could
> recieve a message informing about the scheduled removal and could object
> him/herself. If anyone has to be expelled the DPL/TC/Keyring maintainers
> could apply the change directly.
>
> The same mechanism could be the place for more automatic sanity checks,
> such as, checking whether a key that is about to be added is properly
> signed by a certain required number of other project members, ie.
> something like a "keyring-lintian".
>
> In general and if trust is the default assumption within the project
> such procedure would remove a potential human bottleneck and only
> requires manual intervention if the trust-assumption is violated or
> something happens that is not (yet) covered by a "lintian" check.
>
> Of course such a system could be abused, but the staging of all changes
> would make sure that the environment does not suffer from unexpected,
> harmful changes.
Thinking about this again, 'public' access to the keyring could also be
a way to address the 'large number of inactive developers' -- _if_ they
exist. Anyone could trigger the removal of anybody (using the staging
approach outlined above) -- cleaning the keyring becomes much like mass
bug reporting (and maybe should even follow the same procedure, ie.
announce what you want, let it be discussed publicly, ...)
To not lead into chaos, removals probably have to be handled in a
different manner than additions. It _might_ be perfectly ok for a DD or DM
or DC or whatever to be unresponsive for 3 months -- maybe that should
not lead to the removal from the keyring. A sufficiently long delay for
removals might solve that.
However, if it gets _a lot_ easier to get into the keyring, it even
might not be a big thing if one gets removed temporarily. Just ask to be
added again, and if noone objects, you're in again -- that's it.
Such a rather fast-paced process would let people be members,
contributors, porters, translators when they can afford it to be and not
after having waited for an unnessary amount of time until some central
'master' has decided that is would be 'the right time'. Some people only
have a limited time were they can provided valueable manpower for the
benefit of the project -- and I am not talking about hours per day, but
rather months per life.
Michael
--
GPG key: 1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050
Reply to: