$Id: nm_pp.txt,v 1.41 2004/09/03 09:13:48 tbm Exp $ $Revision: 1.41 $ We have to check that you understand the Social Contract and the Debian Free Software Guidelines (DFSG). Have you read them? If not, please do so. You can find them in /usr/share/doc/debian or on http://www.debian.org/ 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 (current) 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 4 bad licenses. Compare these licenses with the first nine points of the DFSG and show what changes they need to make them DFSG-free. No need to compare word for word, for some licenses this is an impossible task, but you should spot the biggest mistakes. 5a. The GNU Free Documentaion License (FDL) has been heavily discussed on debian-legal recently. Read http://people.debian.org/~srivasta/Position_Statement.html and briefly explain how you feel about the including documents licensed under the FDL in main and what consequences of this position might be for Debian. 6. Are there any sections of the DFSG or Social Contract that you might like to see changed? If so, why? For the answer to the next two questions you need to sign the email. Please dont forget that or I cant accept the answer. 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? I'm sure you have read the Debian Developers' Reference at http://www.debian.org/doc/packaging-manuals/developers-reference/ 7. What are Non-Maintainer Uploads (NMUs) and when would you do an NMU? Please list the usual procedure for a NMU. 8. Tell me 3 different methods to close a bug in the BTS, the difference between them, and when to use which method. 9. 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? 10. How do tags and severities affect the release status of a debian package? 11. Where can you find the list of defined BTS pseudo packages? Explain to me what a Pseudo Package is. 12. You just discovered a bug in many packages. What are your next steps? 13. What would you do if a bug was reported against your package and you are not able to fix it yourself? 14. You've just heard about this great program and would like to package it, what are your next steps? 15. How do you check a package before upload? Please explain to me why and how you perform the checks. 16. What does version 3.4-2.1 mean? What Debian control file would you put this in? 17. 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? 18. 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? 19. 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? 20. 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? 21. How can you ensure your package's description is in a good state and in a valid format? 22. What should you do if a security bug is discovered in one of your packages? 23. 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? 24. Should you happily sign another developer's GPG key? If not please, explain me the checks you will make before signing it. 25. 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? 26. What would you do if you wanted to retire from the project? 27. You need to fix a problem in one of your packages in the stable distribution. Please list all steps you have to do. 28. 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? 29. What do you do if you want to reach the submitter of a bug and keep a copy of the mail in the BTS? 30. 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? 31. At regular intervals, we arrange the so called "Bug Squashing Parties". What are they good for and what happens during such a BSP? 32. 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? 33. 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 and 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; sensitive discussions, flamewars etc. You can unsubscribe if you wish. -devel: general mailing list for developer issues -policy: where possible changes to debian-policy are discussed -mentors: helping newbie Developers. 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 talk about some important websites: 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.