$Id$
$Revision$

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