[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

The Debian Maintainers GR



Hi

The following is basically what I wrote in my blog a few minutes ago,
but IMO should also be on -vote, as thats the place where vote stuff is
handled, and noone can expect people to read blogs or planet...


The DM GR
=========

So, let's join the postings about the currently running Debian
maintainers GR. The short text of this post is _I am against the_
_proposal as it is right now and think it does more harm than good_
and so I did vote for Further Discussion. See below for a bit more about
my reasoning, or just skip if you are already bored. :)


The current proposal does look like a "yay, we have an idea thats not
really thought through. And we do not want to get it into the currently
existing procedures, that would involve more work and discussions. And
anyway, everyone is ranting about the current procedures anyway, so lets
take that bad mood against it to get this done". (And yes, this is a
bit exaggerated, so don't take it personal, please).


As you may have noticed I wrote that I am against the current
proposal when it first was on vote. I was mostly on vacation back then
and didnt want to read the whole thread, so I stayed mostly quiet. I am
not against the DM concept itself. I am against it being
seperate to the existing NM procedure. For me a proper solution
*has* to be integrated with the existing procedures, not seperated.


The main reasons why some support this proposal seem to be

  1. Slow NM process
  2. Someone doesn't want to go through NM
  3. Someone doesn't want to be in the Debian community


Slow NM process
---------------

I am part of this, and not a small one. And yes, I feel (very) bad about
it, but already think about ways this can be changed, after I got the
current backlog done.


Anyway, for this DM thing my backlog isn't the main reason that people
feel NM is slow. It seems to be the general "I have to wait for an
applicant and then answer to a lot of questions and between that wait
and wait and wait".


True. People have to wait at some points, and those waiting periods can
be frustrating. We should do our best to eliminate those waiting places.


The other point is that of the lot of questions. Yes, we have a really
big set of questions in the templates, that cover a whole lot of the
possibly areas a future Developer can work in. And most of those
questions got added after a large set of existing Developers should that
they completly do not know something. That way the templates are
constantly growing and still intend to give the future Developers the
possibility to learn about things in Debian they might never have heard
about. And there is the thought that, if you read about a topic and had
to answer to it in the past, you will at least remember that there is
something if you encounter it in the future.


*But* - there is also the fact that an AM is NOT forced to
use the templates for their process. AMs are, and have always been, free
to do the process on their own. There are some questions every AM *has*
to ask, but thats a minority. If you look at the templates you will
spot the needed ones easily. Other than those every AM can freely do
whatever he wants to do with his applicant (as long as the applicant
agrees to do that stuff and its legal :) ). The AM only has to keep
the following in mind: Both, FrontDesk and DAM, usually do not work
together with the applicant. They might have heard the applicants name
at some point, in some bugreport or some packages Maintainer: field. But
they usually did not interact with them. Which means that the AM has to
make sure that FD and DAM are able to build up their opinion of the
applicant *just by reading the mailbox of the AM<->NM communication*.
Which usually means: read between 20 - 70 mails of a communication
someone else had before you decide if someone should or should not enter
Debian. (Leaving alone checking packages.qa, lintian, bug lists and a
bit of google).



Someone doesn't want to go through NM
-------------------------------------

Erm. Well. Then use sponsors for your packages. Or is it because you
think NM is too hard? NM isn't that hard, everyone that can read and
write english texts (even if the english is bad) and use google
*is* able to pass NM. (For the bad english - if you fear joining NM
because of that: Well. If I go and reread my own report from back when I
joined - ugh. I hate my english. And I know native people *still*
hate my english texts, its named en_GANNEFF for a reason. :)
It is not necessary for your English to be perfect; you only have to be
able to make yourself understood. If an AM doesn't understand what you
wrote they can simply ask for clarification).


DM also doesn't help for people that don't want to pass NM. They have to
pass the advocate, the ID check and the same minimum set of of questions
NMs have (as written a bit above). So you already have a large part of
NM for the future DMs.



Someone doesn't want to be in the Debian community
--------------------------------------------------

Then they shouldn't be able to upload on their own. They can use
sponsors. After all the only thing you must do as a DD is to read
debian-devel-announce. And thats something a DM also must do, or you
can't seriously consider to package anything. And then DD only adds
rights for you, like taking part in votes and so expressing your
opinion and getting things changed in Debian that you may not like.


========================================================================

How to integrate a concept of DM then?
--------------------------------------

First - by starting in the right area - getting it into the NM system by
talking to all those involved. There is FrontDesk, DAM and also the
NM-Committee, the latter should be the right point for a proposal and
discussion.


What I can imagine that would work and do something good is a system
integrated into NM that gives future Developers upload privileges after
they passed a few steps with their AM. That way they can upload early in
the process, which can then be part of the T&S set, and the following
steps in their NM process "just" slowly add more rights to the NM until
its the set of rights every DD has.


Seen from the current layout of the process it would be somewhere after
the ID check and the first set of P&P, ie. at the time the AM sends the
second P&P part. After that point the AM could
recommend to those maintaining the DM list that the applicant should be
added to it, together with a list of packages where the applicant is
allowed to upload them. The maintainers of that DM list could be
FrontDesk + DAM + maybe someone else, but thats something to
discuss. And list of packages - while one could take the current limits
the GR wants to set or simply a plain list, that can be amended during
the time someone is a DM.


Now, one can add a turnoff for people that do not want to pass through
the rest of the process at this place. Im not sure its such a good idea,
but thats something one can discuss. But if so it should be attached to
some rules like - must read our debian-devel-announce list, is included
in regular pings of activity similar to the wat ping.

-- 
bye Joerg
1. 0  2. 1  3. 2  4. 3  5. 4  6. 5  7. 6  8. 7
|-) What sort of FTP proxy firewall do you have?
           -- libnet-perl 1.16-1

Attachment: pgpe8vqkk3mMr.pgp
Description: PGP signature


Reply to: