Re: Debian Membership
"Giacomo A. Catenazzi" <cate@debian.org> writes:
> Matthew Johnson wrote:
>> My goals with changing the membership procedures are:
>>
>> - To turn NM into a more evolutionary process where some privileges and
>> rights are granted earlier in the process and the qualifications for the
>> later parts are based mainly on the work done with the reduced privileges
>>
>> - To make some of those reduced privileges legitimate goals for people to
>> aspire to in their own right
>>
>> - To acknowledge more types of contribution
>>
>> - To retain at least some of the oversight and checks of the current NM
>> process for all of the technical parts of the membership process
>>
>> - To decouple of technical and political positions in the membership
>>
>> Being part of the project, particularly with upload rights, is something I
>> believe _should_ be difficult. This restriction on access to the archive is one
>> of our strengths, it gives us a higher quality of packaging (yes, there are
>> exceptions, but they should be the exception, not the rule) than would
>> otherwise be possible.
>
> I'm confused about your intents, reading last quoted paragraph with the
> "To turn NM into a more evolutionary process".
>
> I totally agree that the upload right should be difficult to gain.
> But the frequent discussions about NEW queue give us a lot of informations:
> - we want easier upload right (e.g. for NEW packages)
> - we suck on upload quality (only on NEW queue ???)
> - we must be anal/fundamentalist on license checks (not only on NEW queue).
I think that plays nicely with his first point, reduced
privileges. Debian already has some of that with the DM/DD split.
There are different kinds of packages in debian that require different
skills:
- binary packages, data packages
- simple library packages
- mixed binary/library/data packages
Also there is a big difference between the NEW packages and existing
packages. Getting things right the first time is much more difficult
than keeping a package current.
So why not have a set of rights. Initially people only have right to
maintain a package and all uploads must be sponsored. After some
successfull uploads the maintainer could get rights to upload existing
packages. After a few new binary debs (e.g. soname transitions of a
library) he could gain rights to upload new binary debs for existing
sources to NEW. And if someone shows an aptitude for creating new
source package and judging license issues then he could gain that
right.
This could also be coupled with steps in the NM
process. E.g. the Task&Skill section would be required before any
upload rights.
On the other hand I don't see why someone needs to maintain a package
master packaging to get access to debian-private? Something a
translator wouldn't need at all.
> Thus:
> - we (DD) must improve => I would like some QA on existing DDs on new proposal
It would be good if some existing bad apples loose their rights. Screw
up a library transition -> loose binary upload rights to NEW. As for
NEW source packages maybe everyone should loose that with the
exception of a willing bunch of good DDs and then more can be added
when they show they can do it. Call it the NEW team. They could vet
packages before they take up ftp-master time.
> - how can we trust to DMs, if they don't have technical review and license review?
By restricting them to what we've observed they can do and gradualy
give rights as they demonstrate further skills.
> The last point seems to contradict common interpretation of "to turn NM into a
> more evolutionary process".
>
> In conclusion:
> - a agree with more type of contributors, and more fine grained access control
> (translators, bug checkers and patcher, QA, infrastructure ...)
> - vote only on "makers" (uploader, translator, ...) (who makes something in last years).
> - upload should be difficult
> - quality control on existing members (to force not to be to lazy)
Becoming a member with minimal rights should be easy. That is where I
think DM goes totaly wrong. It makes uploads easier and becoming a
member harder.
For example a maintainer should have rights to log into debian
machines and track down bugs in their package before they have the
right to upload on their own. Let them demonstrate they can fix bugs
even on architectures other than their own.
> ciao
> cate
MfG
Goswin
Reply to: