>> while keeping the spirit of easing entry into Debian for newcomers.
>> At the same time we add a separate track for less-technical
>> contributors.
> Is it a start of a discussion? A new policy?
Both. :)
It is
- a start of the discussion, using d-d-a on purpose to reach
everyone in something that more or less touches all of us, and
- a new policy to get implemented some time soon, with whatever
sensible changes might come out of this thread
On 11547 March 1977, Margarita Manterola wrote:
> I have been wanting this for a long time, I totally agree with what's
> in the mail, and I'm really happy that this has been thought about and
> written about, however, I'm quite disappointed on this being informed
> as a done thing, without the project as a whole being asked for an
> opinion.
None of this is implemented yet, all of this requires work in multiple
places (changing nm.d.o, changing dak are two examples)
> I know that DAM's and Front Desk and the like and in charge of
> accounts, but creating 2 new categories for people to participate in
> is quite a change, and I think the whole project should be involved in
> such a decision, as we were involved in the decision regarding Debian
> Maintainers.
While this is a long text (to properly explain the thing), it doesn't
change as much as people seem to think.
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.
> 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.
6. no change to now
7. is "DM-Team" approval now
8. is "DM-Team" keyring foo stuff now
9. this can easily be in 7., and only get invoked if you want to add
more packages to your list later
[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.
On 11547 March 1977, Felipe Sateler wrote:
>> Now let us describe the way the account status is meant to be handled
>> in future.
> This mail has mixed future and present tense. Have these changes already been
> implemented, or are planned?
Those changes do require some work in multiple places. So its not
implemented yet, no.
>> While, strictly speaking, this increases the barrier to get DM compared
>> to the current implementation of DM, we do not think it is an
>> unreasonable or too high level. Anyone who is able to get a package put
>> together in a lintian clean way will be able to get DM without much
>> effort or time used.
> So this basically requires DMs to do the (somewhat reduced) P&P and T&S
> questions, and I don't see the real reason for this. The idea behind DMs is to
> maintain a package one knows how to maintain. The only reason I can see here is
> that DDs are not being trusted in their advocations, which is a far worse
> problem that won't get solved by this.
As written above, the actual amount of checks DM have to do is left to
the NM Committee and can be adjusted as needed.
This does *IMO* not contradict DM, but it enhances the value of it in
the long term. Right now you can be DM, but have to pass the full NM
before you can get DD. In future you get DM (and yes, you have a tiny
amount of more work to do for this), be it for a few months and then you
can get DD relatively easy by just doing the last few steps
needed. Ie. once you are a DM you are already about half through NM.
>> Those two "classes" are the initial set in which every NM will end
>> up. After six months as DC or DM one might chose to become a
>> Debian Member or Debian Developer. This
>> - ensures that the interest in Debian isn't short-term.
> Why do people keep thinking this is a good thing?
Because short term involvement usually creates more work than it helps, IME?
>> - enables them to learn more about the workings in Debian and generally
>> helps them for the next step.
> They should be doing this on their own, and not force an arbitrary limit on
> them. What if they did this _before_ applying for DD/DME/DM/DC status?
Then it will be a no-brainer to pass the rest in this
process. Unfortunately a large number of people trying to join Debian
did not do that before applying, as past has shown us.
> This all smells like a whole lot of bureocracy for no gain to me.
I do see the gain for everyone that wants to join and also for those
non-technical people that do help to make Debian better. Not everything
in Debian is about packaging alone, even if some people (not attacking
you, thats a general some) love to think there is nothing besides
packages. We do want translators, we do want documentation writers, they
all help to make Debian even more the Universal OS by opening it up to
those not speaking english. Or those that aren't the most clueful ones
in technical things and just want to use a great OS to get their daily
work done.
Yes, the most important part in Debian is about packaging, without this
there won't be a place for translators/documentation writers, but that
doesn't mean we should ignore or deny their existance.
--
bye, Joerg
> commited with the quality of our system (and project), it is all very
> connected: Freedom <-> Users <-> Quality <-> Transparency <-> Freedom.
This looks like a consulting schema
Attachment:
pgp9_oOROJDQe.pgp
Description: PGP signature