[Nm-templates-discuss] templates nm_advocate.txt,NONE,1.1 nm_pp1.txt,NONE,1.1 nm_pp2.txt,NONE,1.1 nm_ts1.txt,NONE,1.1 nm_ts2.txt,NONE,1.1 nm_assigned.txt,1.17,1.18 nm_pp.txt,1.47,NONE nm_ts.txt,1.23,NONE
joerg@haydn.debian.org
joerg@haydn.debian.org
Update of /cvsroot/nm-templates/templates
In directory haydn:/tmp/cvs-serv6939
Modified Files:
nm_assigned.txt
Added Files:
nm_advocate.txt nm_pp1.txt nm_pp2.txt nm_ts1.txt nm_ts2.txt
Removed Files:
nm_pp.txt nm_ts.txt
Log Message:
Added a mail to the advocate/sponsor of the applicant to get some more informations.
Maybe this should be integrated into the automatic advocate mails.
Modified assigned.txt:
- Mention that it is good to have more sigs than just the one absolutely needed
for the ID check
- Changed the stuff about the package, its more detailed in 2. step of T&S now.
- added a paragraph that one can ask if there are problems with questions.
Splitted the templates for P&P and T&S:
- Now there are two files with questions for both parts. They should all be used
IMO, as they are splitted (and a bit rewritten) but still the same.
The first P&P now checks the absolutely important things like SC/DFSG (Philosophy),
the second part the Procedures stuff.
T&S isnt so easy to split, it is now a 3 step thing. First two sets of questions
and small tasks, then a thorough package check.
With the first T&S mail there is now the mention of dak.ganneff.de and the account.
AMs should simply mail the keyid of the applicant to ftpmaster@dak.ganneff.de to
give the NM an account there.
--- NEW FILE: nm_advocate.txt ---
Hello NAME,
You have either advocated the NM application or sponsored packages of
NM_NAME whom I have been appointed for as Application Manager. Due to
your cooperation with him, you probably know much more about him than I
do. Thus, I would like to ask you to give me a short overview about:
1) How the cooperation between you and him worked so far
2) How he handles his tasks
3) How he handles problems
4) His social skills (How does he treat users? Other developers?)
4) Whether he is reliable or not
(Your reply will probably get included verbatim in the final report)
I thank you in advance for your answers.
--- NEW FILE: nm_pp1.txt ---
$Id: nm_pp1.txt,v 1.1 2005/01/06 22:16:06 joerg Exp $
$Revision: 1.1 $
OK, here we go with P&P, checking your knowledge of Debian policies and
procedures. In preparation, you should read the Debian constitution[1],
Social Contract[2] and the Free Software Guidelines, and finally the
developer's reference[3] and the current version of Debian policy[4].
After you have done this, please answer the following set of questions
and try to be quite verbose in your answers. This, and the next half of
P&P are the main areas that we can only check via your written
communications (no packages or keys to go on), so the more you can tell
me (which means the less prodding replies), the better. :)
First, please explain the key points of the Social Contract and the
DFSG _in your own words_. Also, describe what you personally think
about these documents.
Secondly, a few questions, based on them:
0. What is Debian's approach to non-free software? Why? Is non-free
part of the Debian System?
1. Suppose that Debian were offered a Debian-specific license to
package a certain piece of software: would we put it in main?
2. Donald Knuth, author of TeX, insists that no-one has the right to
modify the source code of TeX, and that any changes must be made using
"change files" (a sort of patch file). Is this allowed for a program
for the main section of Debian?
3. Do you know (and can you explain) the difference between free speech
and free beer? Is Debian mainly about free speech or free beer?
4. The e-mail client pine is in non-free. Can you tell me the
difference between main, contrib and non-free? Do you know what's
wrong with Pine's current license in regard to the DFSG? (You can
read the license here:
http://www.washington.edu/pine/overview/legal.html)
5. At http://people.debian.org/~joerg/bad.licenses.tar.bz2 you can
find a tarball of bad licenses. Please compare the graphviz and two
other (your choice) licenses with the first nine points of the DFSG
and show what changes would be needed to make them DFSG-free.
There's no need to compare word for word (which would be impossible
for some licenses anyway), but you should spot the biggest mistakes.
5a. The GNU Free Documentation License (FDL) has been heavily discussed
on debian-legal recently. Please read
http://people.debian.org/~srivasta/Position_Statement.html and
briefly explain how you feel about including documents
licensed under the FDL in main and what the consequences of this
position might be for Debian.
5b. How do *you* check if a license is DFSG-compatible?
5c. There are a few "tests" for this purpose, they are based on [not
really] common situations. Do you know one (or more) of these?
Explain it/them to me and point out which common problems can be
discovered by it/them.
6. Are there any sections of the DFSG or Social Contract that you
might like to see changed? If so, which ones, and why?
Do you agree to uphold the Social Contract and the DFSG in your Debian
work?
If you are accepted as a Debian developer, you will get accounts
on the Debian machines. Have you read the Debian Machine Usage
Policies (DMUP) at http://www.debian.org/devel/dmup ? Do you
accept them?
After you have mailed this back to me (you need to sign this mail with
GPG, please don't forget this), I will go over your answers. If all is
satisfactory, I will give you phase II of the P&P test.
URLs:
[1] http://www.debian.org/devel/constitution
Constitution for the Debian Project
[2] http://www.debian.org/social_contract.en.html
Debian Social Contract
[3] http://www.debian.org/doc/developers-reference/
Debian Developer's Reference
[4] http://www.debian.org/doc/debian-policy/
Debian Policy Manual
--- NEW FILE: nm_pp2.txt ---
$Id: nm_pp2.txt,v 1.1 2005/01/06 22:16:06 joerg Exp $
$Revision: 1.1 $
So now we are done with the first half of P&P lets go on to the second
half. The next phase of the Policy and Procedures test examines your
understanding of basic Debian rules and the proper method of interacting
with Debian resources.
I'm sure you have read the Documents I mentioned in the first half of
P&P. They should help you to answer these questions, but you may also
look at the bottom of this mail, where I list a few other URLs to help
you.
1. What are Non-Maintainer Uploads (NMUs) and when would you do an NMU?
Please list the usual procedure for a NMU.
2. Please tell me 3 different methods to close a bug in the BTS, the
difference between them, and when to use which method.
3. Each bugreport has a severity and optionally one or more tags. What's
the difference between these two (severity and tags)? How do you set
them?
4. How do tags and severities affect the release status of a debian package?
5. Where can you find the list of defined BTS pseudo packages?
Explain to me what a Pseudo Package is.
6. You just discovered a bug in many packages. What are your next
steps?
7. What would you do if a bug was reported against your package and
you are not able to fix it yourself?
8. You've just heard about this great program and would like to package
it, what are your next steps?
9. How do you check a package before you upload? Please explain to me
why and how you perform the checks.
10. What does version 3.4-2.1 mean? What Debian control file would you
put this in?
11. You have a new package, and you finally find that it will be in
contrib. Why would it be there? What could you do (in theory at
least) to get it into main?
12. If you had a file in your package which usually gets changed by a
administrator for local settings, how do you make sure your next version
of the package doesn't overwrite it?
13. What is an autobuilder? Where can you find information about your
package's build status on different architectures? What can you do
if you think there is a problem with the autobuilder?
14. There are many Debian suites, like "stable", "unstable", "testing",
"woody", "sarge" and "sid". Can you explain why there are so many
and what the differences are? How does a package get from one to
the other?
15. How can you ensure your package's description is in a good state and
in a valid format?
16. What should you do if a security bug is discovered in one of your packages?
17. Imagine you maintain a package which depends very closely to some
other package. How would you keep track of the development of other
packages, even if you are not the maintainer?
18. Should you happily sign another developer's GPG key? If not,
please explain the checks you will make before signing it.
19. Do you know how to create a revocation certificate for your GPG key?
Do you have one? Why can it be meaningful to set a key expiration date?
20. What would you do if you wanted to retire from the project?
21. You need to fix a problem in one of your packages in the stable
distribution. Please list all steps you have to do.
22. Someone files a bug against a package that you maintain. However, the
problem in the bug report does not come from a bug in your package, but
rather a bug in another maintainer's package. How should you handle
the bug that was filed against your package?
23. What do you do if you want to reach the submitter of a bug and keep a
copy of the mail in the BTS?
24. Again, something BTS related: Consider you have a package, with a
set of open bugs. Some of them fixed by the new upstream version
(which you are about to upload), some of them aren't really bugs, or
are not relevant anymore (because they were fixed ages ago, for
example). How would you handle them?
25. At regular intervals, we arrange the so called "Bug Squashing Parties".
What are they good for and what happens during such a BSP?
26. Although english is doubtless the "lingua franca" nowadays, which means
that it is nearly everywhere understood, there are still some users who
can't understand it properly. Which efforts does the Debian project make
to help these people?
27. Please list some tasks that belong to the scope of duties of the Debian
Quality Assurance group.
A word on mailing lists: there are quite a lot of Debian mailing lists
now as well as packaging-related packages, and I'd just like to check with
you whether you know about the key ones.
debian-announce: Major public announcements
debian-devel-announce: Major announcements to the developer community
These two lists are must-subscribes. Everything else is optional. I
abbreviate 'debian-' to '-' from now on.
-security-announce:
security updates to stable
-private: you'll be subscribed automatically when your new-maintainer
application is accepted (but you can unsubscribe if you wish);
the list is used for sensitive discussions, etc.
-devel: general mailing list for developer issues
-policy: where possible changes to debian-policy are discussed
-mentors: helping newbie Developers.
-project: project related discussions
There are many others; check the mailing list page on the web site
for details.
Now lets take a look at some important packages for a (upcoming) Debian
Developer. There are many of them, I will try to list the more important
ones.
build-essential
A package that depends on all the packages in the build
essential list. It's useful to make sure everything in the list
is installed on the system when building and testing your own
packages.
dpkg-dev All of the primary tools needed to put a Debian package
together: dpkg-buildpackage, dpkg-source, etc.
debhelper A very useful set of scripts designed to make
debian/rules files more readable and uniform.
But you should be able to build a package without it.
debian-policy
Describes the policy relating to packages and details of
the packaging mechanism. Covers everything from
required gcc options to the way the maintainer scripts
(postinst etc.) work, package sections and priorities,
etc. An absolute must-read. Also useful is the file
/usr/share/doc/debian-policy/upgrading-checklist.txt.gz,
which lists changes between versions of policy.
You must read and understand it.
doc-debian Lots of useful Debian-specific documentation: the
constitution and DFSG, explanation of the Bug Tracking
System (BTS), etc.
maint-guide
The New Maintainer's Guide to making Debian packages.
devscripts Lots of useful (and not-so-useful) scripts to help build
packages.
developers-reference
Lots of information on procedures and suchlike.
dupload or dput
Automatically upload packages to the archive once they
are built.
fakeroot Build packages without having to be root.
reportbug Tool to report bugs.
debootstrap
Allows you to "install" Debian's base on a given directory
anywhere on the filesystem. Combined with a chroot and
build-essential, this makes for a nice way to have a clean
environment where you can build your packages.
pbuilder Gives you an easy way to use debootstrap to test your
packages in a sane environment
sbuild Tool to build your packages in a chroot (useful for
verifying build-deps)
lintian
linda Two packages to check your package for commonly made
errors. You should never upload a package which is not
checked by one of these tools.
Finally, some important web links:
http://www.debian.org/devel/
The Developer's Corner. Contains links and on-line versions
of the stuff I mentioned before.
http://db.debian.org/
Queries about developers and machines
http://www.debian.org/devel/wnpp/
The Work Needing and Prospective Packages list. Sort of a
big TODO list for Debian packaging stuff: what's orphaned,
what needs new maintainers, what's being adopted, what's
being packaged and what would be nice to have packaged.
http://qa.debian.org/
The Debian Quality Assurance headquarters. Help is appreciated!
http://bugs.debian.org/
Bug related info
http://www.debian.org/security/
Security related info. Please, read the FAQ, as it will save
you (and others) a lot of headaches
http://packages.debian.org/
Package related info
http://buildd.debian.org/
Build status of Debian packages
http://lists.debian.org/
Mailing list subscription and archives
http://qa.debian.org/developer.php
An interesting place to keep track of your packages.
http://lintian.debian.org/
Automated lintian tests on all packages in the Debian Archive.
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
Debian Library Packaging guide
http://packages.qa.debian.org/
The Package Tracking System
http://people.debian.org/~walters/descriptions.html
A small Guide "Writing Debian package descriptions"
http://people.debian.org/~igloo/status.php
Watch your package status.
http://people.debian.org/~bap/dfsg-faq.html
DFSG and Software License FAQ
--- NEW FILE: nm_ts1.txt ---
$Id: nm_ts1.txt,v 1.1 2005/01/06 22:16:06 joerg Exp $
$Revision: 1.1 $
Lets go to the next big part of your application - the check of Tasks &
Skills. Similar to the P&P we just finished it is also splitted, this
time in 3 steps. These steps are 2 parts of Questions together with a
severe check of your package(s).
There is also a place where you can go and upload your package. The
archive at that site works exactly the same as the Debian archive, in
fact it uses the same software behind the scene. So you can take this as
the opportunity to get used to uploads and the stuff that happens with
your packages, you are not just left alone after your NM without any
knowledge what exactly you need to do to get a package into the
archive.
For more information please read http://dak.ganneff.de/dak.txt and also
the email you should get in a short timeframe from that archive. It will
tell you your accountname there, and a few other details you may want to
know.
After we finished the two steps with the questions I will get the
package you uploaded to that archive and check that. So please take the
time until then and prepare the best package out of it. :)
Finally, the first half of the questions:
If you have filed bugreports (with patches) to the BTS with respect to
packaging issues, please tell me bug numbers, so I can check them.
0. What is the best way to check that your Build-Depends Line contains
everything required to build your package?
1. Please explain me what a virtual package is. Where can you find a
list of defined virtual packages?
2. What does it mean for a package to have a line like
"Architecture: i386 alpha powerpc" in the control file?
Do you have to provide binary packages for all these
architectures if you upload your package?
What is the difference between "Architecture: all" and
"Architecture: any"?
3. How do you manage new upstream releases?
4. There is a bug in your package, fixed in Upstream CVS/development
branch. What do you do with it?
5. What do you do if Upstream releases a tarball once every year and
then distributes minor revisions only in the form of patches? How do
you manage your package then?
6. What is the difference between native packages and non-native
packages?
7. What is an epoch? When would you use one?
8. Explain the difference between Depends, Recommends and Suggests.
9. How does Debian handle run levels?
What runlevels are related? How does this interact with users' local
modifications?
What should packages which require starting up and shutting down
(like daemons do) do?
A. Tell me the differences between /usr/share and /usr/lib.
B. Please list some good reasons for a package split.
C. What would you need to do if upstream changed the name of the
application? What would you do to assure smooth upgrades?
D. What is Pre-depends for? Why should you avoid it?
E. a. Have you ever written a man page? If so, please tell me which. If not,
please take a look at http://qa.debian.org/man-pages.html and
choose a package listed there. Then please write a man page for it,
submit it to the BTS and tell me the bug number for it please.
b. Please look at http://bugs.debian.org/release-critical/debian/all.html,
choose a bug listed there (please try to find one older than a few
days), try to create a patch to fix it and submit this patch to
the BTS. If you can't fix the bug, you should document what
you've found out about the bug in the BTS.
Then prepare, if possible, a NMU and send me a pointer to your NMU patch.
Do the same thing again for 2 other bugs with severity Important
or higher again.
If you couldn't fix a bug, you should send me the bug number of the
one you tried to fix.
F. Write a small shell script which does the following two things:
a. prints whether a Debian package archive file has a copyright file
in the appropriate location.
b. prints out the package version from the control file which is
inside the .deb.
You may use tar, ar, grep, etc., but not any middle or high-level
dpkg tools.
Weeh, that is the first half. Take your time to answer them, but please
don't take forever. There is more waiting for you and we all want to get
this to a good end, do we?
--- NEW FILE: nm_ts2.txt ---
$Id: nm_ts2.txt,v 1.1 2005/01/06 22:16:07 joerg Exp $
$Revision: 1.1 $
Nice, we finished with the first half of the T&S Question set. Let's go
on with the second half, which contains additional stuff I want to know
from you.
1. Why does a foo-dev package depends on foo?
Why is it fooX-dev and not foo-dev in some cases?
2. When would you use the alternatives system, and how?
3. How can you minimize the downtime of a service during upgrade?
Be specific about how you'd use the maintainer scripts.
4. What are FTBFS bugs? How would you avoid them?
5. What would you do if a package has no sane default configuration?
(There is *no* default configuration that works on most systems!)
6. What would you do if your package contains an Emacs major mode?
If you don't use/know Emacs then this: What would you do if your
package contains a perl module? Or if it is python?
No Emacs, no Perl, no Python? Go away. Or tell me what to do if you package
something Java related. :)
7. How does Debian maintain consistency between different Windowmanager menus?
8. What are base, standard, optional and extra? Why are they useful?
What is Essential: yes? Why isn't libc Essential? Why isn't the
kernel? Why can't libc be essential? Why does libc not need to be
essential?
9. What does the "urgency" field in changelog affect? When would you use
which urgency?
A. What are maintainer scripts? What arguments does each get?
What is the meaning of the arguments? What can each of them
assume about the system?
B. How does a porter handle a rebuild?
C. a. If you want to sponsor a package upload, what do you need to do?
b. Please take a random package out of the archive and send me the
.changes file as it would look if you're sponsoring the upload
of this package.
D. What is the difference between experimental and unstable?
E. What would you do if you had a package which includes a mix of
Architecture-dependent and architecture-independent files?
F. Dpkg does not support versioned provides.
Explain what that means, and list common workarounds.
G. There is a minimal set of packages you never need to Build-Depend
on. Tell me which and why.
H. What build target would you use in debian/rules to build a package
which includes only Non-architecture-dependent files? What is the
"Architecture:" section for this package?
I. Fundamental runtime linker knowledge:
I0. What are library sonames, and what are they used for? What is the
"ELF" format?
I1. How does the utility "fakeroot" work? How is that tied to
LD_PRELOAD, and the runtime linker?
I2. What is a symbol-versioned library? Why are libdb2, libdb3 and libc6
compiled using symbol versioning? What problems does symbol-versioning
solve?
I3. What is the -Bsymbolic ld flag, exactly what does it do, and how
that differs from library symbol versioning? What problems do
-Bsymbolic linking solve? Why is libc6 not compiled with
-Bsymbolic?
J. What is endianess and why does it matter when supporting multiple
architectures?
You are finished with the questions. As I already announced with my
first T&S mail, I will check your package after you answered the
questions above. So please upload the latest and greatest version to the
archive at dak.ganneff.de and tell me the names of your packages.
Index: nm_assigned.txt
===================================================================
RCS file: /cvsroot/nm-templates/templates/nm_assigned.txt,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -d -r1.17 -r1.18
--- nm_assigned.txt 14 Mar 2004 17:28:27 -0000 1.17
+++ nm_assigned.txt 6 Jan 2005 22:16:06 -0000 1.18
@@ -40,6 +40,20 @@
know and we can discuss it. Usually I can find someone that lives near
you that would agree to meet you and sign your key.
+Besides the requirement to have a signature from at least one existing
+Debian Developer there is a strong advice to get more signatures on your
+key and to make sure you are in the strong set of keys. Of course no one
+request you to be at the top position in the world-wide Web of Trust,
+but you should try to get at least into the strong set of keys. A site
+to check whats up with your key is
+http://www.cs.uu.nl/people/henkp/henkp/pgp/pathfinder/
+Enter your keyid in the statistic box and see some stats about it. If it
+complains it can't find your key, and you are sure you have used the
+right ID it means that you are not in the strong set of keys, which is
+not very good. This is not a showstopper for this application, but you
+should try to get more signatures by meeting other people, exchanging
+signatures, etc.
+
Please sign all mail to me. It's not that I'm paranoid about security,
it's just a good habit to get in to, and it shows me that you know
how.
@@ -59,11 +73,20 @@
If you have packaged an application for Debian already, please take
another deep look into it, eliminating any error you may find. When we
-start with T&S, you will need to send me its sources, so I can review it.
-If it is a big package just give me the URLs where i can download the files
-with wget.
-Please also give me the Name of your sponsor for your package if it is
-already in the Debian Archive.
+start with T&S, you will get more information about the package check
+and a place where you can upload it.
+
+A thing I should mention: I will ask you a lot of Questions in this
+process. This is not torture you, it is to check your knowledge and to
+point you into the right directions where you may miss something at the
+moment. After all the questions were developed in the last few years
+and every little one has an own reason why it is there.
+Yes, i must admit that some are not so easy to solve, but normally a bit
+of thinking mixed with google and the pointers I give in the various
+next mails should help you, so I simply expect you can answer all of
+them. But before you die over one of it - come back and talk with me, I
+can give you some hints. After all, the process should enhance your
+knowledge and should not make your life to tough.
I look forward to hearing from you and hope we will be able to go
through the steps without any problems. The next step is "Philosophy
--- nm_pp.txt DELETED ---
--- nm_ts.txt DELETED ---