Re: Developer Status
Joerg Jaspert wrote:
>
> On 11547 March 1977, Raphael Geissert wrote:
>>> Debian Maintainer
>>> -----------------
>>> They are allowed to upload their own (source) package. The allowed list
>>> of (source) packages to upload can be edited by any member of the NM
>>> committee[NMC], who will do a package check before they add new packages
>>> to the DM's list.
>> I believe everything is ok up to this point: why does the "NMC" need to
>> review the packages? I mean: has there been any problem with the current way
>> DMs are allowed to upload? can't <the project> trust in DDs as to what
>> packages can DMs upload?
>
> We do trust DDs - everyone can become a member of the NM Committee,
> you just have to do a little AM work.
"...you just have to do a /little/ extra work" I would say. I don't think that's
the right way to do it.
If a "reviewing team" is really needed it should be built from the QA side, not
from the management/NM side. Which would thereby have to drop the AM work
requirement and instead put some other sort of requirement, if needed/wanted.
>
>> By adding this extra step it makes the process more complex and turns
>> something useful into something more like a process with lots of paper-work:
>> It would require to:
>> 1. first: find a sponsor to upload a package,
>> 2. then become trusted,
>> 3. get advocated,
>> 4. ID check (btw, will it still require keys to be signed by DDs? or are DCs
>> or D<whatever> more than enough?),
>> 5. T&S check,
>> 6. SOC agreement,
>> 7. NMC approval,
>> 8. keyring-maints stuff,
>> 9. NMC approval of packages.
>
> Umm, well:
>
> 1. no change to now
> 2. no change to now
> 3. no change to now, only the destination of the approval mail for DMs
> changes
> 4. Yes, this is a change, you need a DD or DME to sign your key.
> One might adjust it so that DC/DM can sign for other DC/DM (or maybe
> make that 2 of them sign one).
> 5. I hope you read the footnote? "It can easily be adjusted to fit
> whatever the current situation is". Which means that they can make it a
> full T&S plus "must fix 1000 RC bugs" - or just nothing.
Yes, but my concern is about turning that part into templates that fit
everyone[tm]; just like the current NM process.
> 6. no change to now
> 7. is "DM-Team" approval now
> 8. is "DM-Team" keyring foo stuff now
7 and 8 are only one right now.
> 9. this can easily be in 7., and only get invoked if you want to add
> more packages to your list later
Which makes the process more complex.
>
> [DCDMQ] The intention is that the NM-Committee will select the actual
> set of questions used, not this mail. It can easily be adjusted to fit
> whatever the current situation may want to have. For DM we imagine it
> would be a very limited T&S set, like making sure someone can deal
> with the BTS and knows the basic tools (lintian, dput/dupload,
> debsign). It is not meant as a full (first part) of NM and lots of
> boring tasks before one get DM, but as a basic check for a minimum
> knowledge.
>
>>> In contrast to current DM this is based on source packages and allows
>>> uploads of new binary components, which have to pass NEW, too.
>> That's great, but what is it going to happen to cases like #502943?
>
> That is an interesting corner case. (Note that for todays code I'm happy
> to accept patches/git trees to merge to fix any of such errors).
>
> Im currently not 100% sure what the best is in this case.
I'd say first of all take that upload into account to allow the DM to upload the
package, and to comply with the GR check if the package isn't taking over a
binary package from another source package _which is also in the same distro_.
Cheers,
--
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net
Reply to: