From 1dbc65343e41f03c9e0dfca6b8264142acba27f2 Mon Sep 17 00:00:00 2001 From: aph Date: Sun, 5 May 2002 20:44:48 +0000 Subject: [PATCH] - new Chapter "Beyond Packaging" for recommended ways to contribute to Debian beyond issues of package maintenance; Ch "Interaction with Prospective Developers" moved into this chapter and renamed to Sec "Interacting with Prospective Debian Developers" - Section's first word capitalized, rest are normal case - purge a reference to the Packaging Manual; closes: #145039 git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1652 313b444b-1b9f-4f58-a734-7bb04f332e8d --- debian/changelog | 14 ++-- developers-reference.sgml | 141 ++++++++++++++++++++++---------------- 2 files changed, 93 insertions(+), 62 deletions(-) diff --git a/debian/changelog b/debian/changelog index 33478c3..0d82cf8 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,4 +1,4 @@ -developers-reference (2.12) unstable; urgency=low +developers-reference (3.0) unstable; urgency=low * Adam Di Carlo: - some simplifications on the TeX suffix rule @@ -7,9 +7,15 @@ developers-reference (2.12) unstable; urgency=low - update copyright date - Sec "Getting started": link to New Maintainers' Guide - Sec "Debian Mentors" renamed to "Debian Mentors and Sponsors", - we add some info on sponsoring - - -- Adam Di Carlo Sun, 5 May 2002 11:10:20 -0700 + we add some info on sponsoring; also in Sec "Sponsoring packages" + - new Chapter "Beyond Packaging" for recommended ways to contribute + to Debian beyond issues of package maintenance; Ch "Interaction with + Prospective Developers" moved into this chapter and renamed to Sec + "Interacting with Prospective Debian Developers" + - Section's first word capitalized, rest are normal case + - purge a reference to the Packaging Manual; closes: #145039 + + -- Adam Di Carlo Sun, 5 May 2002 13:24:03 -0700 developers-reference (2.11) unstable; urgency=low diff --git a/developers-reference.sgml b/developers-reference.sgml index 8a32ae8..a7f4493 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -5,7 +5,7 @@ %commondata; - + @@ -238,7 +238,7 @@ before actually applying. If you are well prepared, you can save a lot of timer later on. - Debian Mentors and Sponsors + Debian mentors and sponsors

The mailing list &email-debian-mentors; has been set up for novice maintainers who seek help with initial packaging and other @@ -254,11 +254,14 @@ might be able find a sponsor to upload your package for you. Sponsors are people who are official Debian maintainers, and who are willing to critique and upload your packages for you. Sponsorees can request a sponsors at . +

+If you wish to be a mentor and/or sponsor, more information is +available in . Debian Developer's Duties - Maintaining Your Debian Information + Maintaining your Debian information

There's a LDAP database containing many informations concerning all developers, you can access it at . You can @@ -290,7 +293,7 @@ key extraction routines discussed in apply. You can find a more in-depth discussion of Debian key maintenance in the documentation for the debian-keyring package. - Going On Vacation Gracefully + Going on vacation gracefully

Most developers take vacations, and usually this means that they can't work for Debian and they can't be reached by email if any problem occurs. @@ -312,7 +315,7 @@ available in the Debian LDAP database and mark yourself as ``on vacation'' (this information is only accessible to debian developers). Don't forget to remove the ``on vacation'' flag when you come back! - Coordination With Upstream Developers + Coordination With upstream developers

A big part of your job as Debian maintainer will be to stay in contact with the upstream developers. Debian users will sometimes report bugs @@ -331,9 +334,9 @@ developers which can be included there, so that you won't have to modify the sources of the next upstream version. Whatever changes you need, always try not to fork from the upstream sources. - Managing Release Critical Bugs + Managing release-critical bugs

-Release Critical Bugs (RCB) are all bugs that have severity +Release-critical bugs (RCB) are all bugs that have severity critical, grave or serious. Those bugs can delay the Debian release and/or can justify the removal of a package at freeze time. That's why @@ -350,7 +353,7 @@ from the QA group may want to do a Non-Maintainer Upload (see usual before they do their NMU if they have seen no recent activity from you in the BTS). - Quality Assurance Effort + Quality Assurance effort

Even though there is a dedicated group of people for Quality Assurance, QA duties are not reserved solely for them. You can @@ -378,7 +381,7 @@ he maintains and any Release Critical bugs filled against them. Send all this information to &email-debian-qa;, in order to let the QA people do whatever is needed. - Retiring Gracefully + Retiring

If you choose to leave the Debian project, you should make sure you do the following steps: @@ -394,6 +397,68 @@ emailing to &email-debian-keyring;. + + Beyond Packaging +

+Debian is about a lot more than just packaging software and +maintaining those packages. This chapter contains information about +ways, often really critical ways, to contribute to Debian beyond the +simply creating and maintaining packages. +

+As a volunteer organization, Debian relies on the discretion of its +members in choosing what they want to work on, and choosing what is +the most critical thing to spend their time on. + + + + Interacting with prospective Debian developers +

+Debian's success depends on it's ability to attract and retain new and +talented volunteers. If you are an experienced developer, we +recommend that you get involved with the process of brining in new +developers. This section describes how to help new prospective +developers. + + + Sponsoring packages +

+Sponsoring a package means uploading a package for a maintainer who is not +able to do it on their own, a new maintainer applicant. Sponsoring a package +also means accepting responsibility for it. +

+If you wish to volunteer as a sponsor, you can sign up at . +

+New maintainers usually have certain difficulties creating Debian packages +— this is quite understandable. That is why the sponsor is there, to check +the package and verify that it is good enough for inclusion in Debian. +(Note that if the sponsored package is new, the FTP admins will also have to +inspect it before letting it in.) +

+Sponsoring merely by signing the upload or just recompiling is +definitely not recommended. You need to build the source +package just like you would build a package of your own. Remember that it +doesn't matter that you left the prospective developer's name both in the +changelog and the control file, the upload can still be traced to you. +

+If you are an application manager for a prospective developer, you can also +be their sponsor. That way you can also verify the how the applicant is +handling the 'Tasks and Skills' part of their application. + + + Advocating new developers +

+See the page about at the Debian web site. + + Handling new maintainer applications +

+Please see at the Debian web site. + + + + Mailing Lists, Servers, and Other Machines

In this chapter you will find a very brief road map of the Debian @@ -556,7 +621,7 @@ interested in helping Debian. As such, developers generally do not have accounts on these machines. - Other Debian Machines + Other Debian machines

There are other Debian machines which may be made available to you. You can use these for Debian-related purposes as you see fit. Please @@ -1271,7 +1336,7 @@ The program dupload comes with support for uploading to the program for details. - Other Upload Queues + Other upload queues

Another upload queue is available which is based in the US, and is a good backup when there are problems reaching ftp-master. You can @@ -1628,7 +1693,7 @@ a recompile for each architecture, which is amounts to &number-of-arches; more builds. - Being Kind to Porters + Being kind to porters

Porters have a difficult and unique task, since they are required to deal with a large volume of packages. Ideally, every source package @@ -1692,14 +1757,14 @@ although you are probably asking for trouble, since different architectures sometimes standardize on different compilers. Make sure your debian/rules contains separate ``binary-arch'' and -``binary-indep'' targets, as the Debian Packaging Manual requires. +``binary-indep'' targets, as the Debian Policy Manual requires. Make sure that both targets work independently, that is, that you can call the target without having called the other before. To test this, try to run dpkg-buildpackage -b. - Guidelines for Porter Uploads + Guidelines for porter uploads

If the package builds out of the box for the architecture to be ported to, you are in luck and your job is easy. This section applies to @@ -1720,7 +1785,7 @@ binary-only build of only the architecture-dependant portions of the package, using the `binary-arch' target in debian/rules. - Recompilation Binary-Only NMU Versioning + Recompilation binary-only NMU versioning

Sometimes you need to recompile a package against other packages which have been updated, such as libraries. You do have to bump the version @@ -1793,7 +1858,7 @@ the waiting period. Of course, such locations have no official blessing or status, so buyer, beware. - Tools for Porters + Tools for porters

There are several tools available for the porting effort. This section contains a brief introduction to these tools; see the package @@ -1999,7 +2064,7 @@ outlining all the open bugs against your packages: Replace address with you official Debian maintainer address. - Submitting Bugs + Submitting bugs

Often as a package maintainer, you find bugs in other packages or else have bugs reported to your packages which need to be reassigned. The @@ -2019,7 +2084,7 @@ neither the bug submitter nor the package maintainer, you should not actually close the bug (unless you secure permission from the maintainer). - Responding to Bugs + Responding to bugs

Make sure that any discussions you have about bugs are sent both to the original submitter of the bug, and the bug itself (e.g., @@ -2099,46 +2164,6 @@ that the bug report is not forwarded to the bug distribution mailing list. - - Interaction with Prospective Developers - -

-This chapter describes procedures that existing Debian developers should -follow when it comes to dealing with wannabe developers. - - Sponsoring packages -

-Sponsoring a package means uploading a package for a maintainer who is not -able to do it on their own, a new maintainer applicant. Sponsoring a package -also means accepting responsibility for it. -

-New maintainers usually have certain difficulties creating Debian packages -— this is quite understandable. That is why the sponsor is there, to check -the package and verify that it is good enough for inclusion in Debian. -(Note that if the sponsored package is new, the FTP admins will also have to -inspect it before letting it in.) -

-Sponsoring merely by signing the upload or just recompiling is -definitely not recommended. You need to build the source -package just like you would build a package of your own. Remember that it -doesn't matter that you left the prospective developer's name both in the -changelog and the control file, the upload can still be traced to you. -

-If you are an application manager for a prospective developer, you can also -be their sponsor. That way you can also verify the how the applicant is -handling the `Tasks and Skills' part of their application. - - Advocating new developers -

-See the page about at the Debian web site. - - Handling new maintainer applications -

-Please see at the Debian web site. - - Overview of Debian Maintainer Tools

-- 2.30.2