Re: RFC: Changing the NM system
Adrian Bunk wrote:
> My impression is that currently maintainers are accepted too early. For
> some AMs it's enough that they build one package (and thanks to debhelper
> it's relatively easy to build a package) and even if they make a buggy
> package this is sometimes enough to pass the "Tasks & Skills" test (e.g.
> in ). We have currently over 600 developers and at about 6000 packages
> that have over 600 RC bugs. If we don't have severe look at the quality of
> the work of new maintainers it will become very hard to retain our
> reputation of being a high quality distribution.
Maybe it's time to release an idea that I have discussed with Wichert
at LinuxTag '99 and with James at a Linux-Kongress but haven't released
in public yet.
When I stopped the new-maintainer process in '99 I saw similar problems.
I don't want to get into details again but only dump some more stuff for
Regarding the 'Skills Test' I thought of a simple test consisting of
roughly 50 questions. Every maintainer who knows the Debian project
and who knows how the distribution and processes work will be able to
answer the questions in less than two hours. He who does not know
the system etc. will need more time. That's ok. At the end of the
test he knows what he needs to know or knows where to find that
information - if he has answered the questions properly.
Here are the questions I thought about. Please take into account
that this is just a repost of a mail from Jun 12, 1999 and things
may have changed (i.e. debconf isn't mentioned). There is also
one bug included, feel free to find it :)
I'm dissappointed about the large amount of clueless maintainers and
were pondering if it would make sense to make new-maintainer a
The first-stage authority would be a general entrance test which every
wannabe maintainer has to pass. If the entrance-test team approves a
person, it will be processed by the new-maintainer team.
The entrance test could look like this:
1. Why does the Debian distribution exist?
2. Where is PGP (or later Gnupg) used within Debian?
3. Where are private (Debian internal) issues discussed?
4. Where are general development issues discusses?
5. Where are important announcements released for Debian developers?
6. What packages may go into the main archive?
7. What do you do if you lost your password on a machine within the
8. Where do you send your updated pgp/gpg key?
9. What do you do if you haven't gotton a response from the
new-maintainer team two weeks after you sent your request?
10. How do you find out which mailing lists exist on lists.debian.org?
11. How do you subscribe to a mailing list on lists.debian.org?
12. What do you do if you leave for more than one week?
13. What is the preferred method of logging in into a machine within
the debian.org domain?
14. How do you find out who is responsible for a special task within
1. What are pristine source files?
2. How is the source tarball for foo version 2.3 named within Debian?
3. How are source files created as needed by Debian?
4. How do you get to the Debian source tree of a package if the
regular utility is not available, say on a non-debian machine?
5. What is a diff.gz file?
6. What do you do if unneeded files are left over after a regular
clean target and would be included in the Debian source packages?
1. What kind of files is debian/rules?
2. What is the changelog good for
3. Where is the version and name for a binary package taken from?
4. How do you make your package available for architectures you don't
own (say: alpha, sparc, amiga etc.)
5. What is the main target when building binary packages?
1. Where do logfiles go?
2. What is the difference between `dpkg --remove' and `dpkg --purge'?
3. What are `cron.daily', `cron.weekly' and `cron.monthly' good for?
4. What is a menu file good for?
5. Do logfiles need special treatment?
6. What is a shlibs file?
7. How do you add new info-files?
8. Why mustn't you use changelog entries like "* Fixed bug 12345"?
9. What do you do if your package uses /etc/foo.conf for configuration?
10. Where do you put foo.html which is a detailed description of the
package in HTML.
11. How do you test your package against trivial packaging mistakes?
1. Where do you upload a regular package?
2. Where do you upload a package that uses some sort of encryption
with may not be exported out of the USA?
3. When do you make an upload into `stable'?
4. Where do you send an announcement when uploading?
5. What is `contrib' good for?
6. What do you do if your package is "locked" in the Incoming
directory for two weeks?
My intention is to address cluelessness of new-maintainers. The
questions will have to be answered in prosa, phrased by the wannabe
maintainer, or, if possible by a quote from some document. The
intention is that each wannabe maintainer really *knows* what is
Debian about and how it works. Just reading the packaging manual
doesn't mean they have understood it.
I want to improve quality by improving knowledge of new people. I
don't want to rub out new people, I only want to ensure that they
*know* how things work and/or where to find out.
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto
Please always Cc to me when replying to me on the lists.