Differences between revisions 13 and 15 (spanning 2 versions)
Revision 13 as of 2011-05-13 12:30:42
Size: 35199
Editor: ?JakubWilk
Comment: linda is long time dead
Revision 15 as of 2011-05-13 12:36:58
Size: 35162
Editor: ?JakubWilk
Comment:
Deletions are marked like this. Additions are marked like this.
Line 72: Line 72:
If you're interested in helping to fix a bug, there is a [[list of bugs|http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-qa@lists.debian.org;tag=gift]] that have been identified by package maintainers as fairly simple, and good to improve your skills on. For more information, see [[the QA group's wiki page about the tag|http://wiki.debian.org/qa.debian.org/GiftTag]]. If you're interested in helping to fix a bug, there is a [[http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-qa@lists.debian.org;tag=gift|list of bugs]] that have been identified by package maintainers as fairly simple, and good to improve your skills on. For more information, see [[GiftTag|the QA group's wiki page about the tag]].

The debian-mentors FAQ

This FAQ is intended to head off the standard set of questions asked by a large proportion of new posters to the debian-mentors mailing list. There are four sections:

  • General questions, about the list, Debian, and whatever else doesn't fit in another section.

  • Packaging, issues relating to creating and maintaining Debian packages.

  • Sponsored packages, all about the purpose and process of package sponsorship.

  • For sponsors, info for developers sponsoring or considering sponsoring a package or two.

If in doubt, just read the whole thing. If you still have your question, ask on the debian-mentors list.

General questions

What is the debian-mentors mailing list for?

debian-mentors is for the mentoring of new and prospective debian developers. Almost any question relating to Debian development is potentially on-topic for d-mentors. Although there are other lists which deal with most aspects of developing for Debian, they're often pretty hard core and can be daunting. If you think your question might be a little "newbie" for the hardcore developers on debian-devel, then it's probably a good fit for -mentors.

In short, we aim to be the "softer, gentler" Debian development mailing list.

One of the most common uses for the list is to attempt to get a sponsor for a piece of software you've packaged (or are intending to package). It's such a common request that it has it's own section in this FAQ.

Things that aren't really appropriate for -mentors:

  • Questions about using the debian system, either as a regular user or an admin. These would tend to belong in debian-user or a list devoted to the particular subsystem you're using (debian-x, debian-apache, etc).
  • Questions about programming in general. This would be a topic for a list or forum dedicated to the language or system used.
  • Hard-core debian development questions. Although -mentors will try and help out, you'll get the big brains working on your problem if you take it next door to debian-devel, or to one of the topic-specific debian lists.

I want to help Debian. Tell me what I can do.

This is a very difficult question to respond to, because there's so many different things that could be done, and we don't know what you're really interested in doing. Particular problems include:

  • It's hard to know what you actually want to do. Even with a detailed resume, how do we know whether you're going to be interested, long term, in doing some task. Remember that everyone's a volunteer, and we have no hold over you to tell you to do something you don't want to do (unlike paid employment).
  • If someone spends a lot of time specifying a task for you to do, and then you decide you don't want to do it, then they've wasted time they could have spent doing whatever it is that they do. After you've had this experience a few times, you just stop specifying tasks for people. Instead, just dive into something and try and work out how it's done. Hands-on learning is the best type of learning anyway.

If you really are keen on getting involved in random places in Debian, there are lots of resources in the question "What can I do to help Debian other than packaging?", below.

What's the process of becoming a Debian Developer?

The perennial question. As provided by Andreas Metzler (I couldn't have put it better myself, so why bother trying?):

  1. Package stuff. See How do I make my first package? for more details on that aspect of the process.

  2. Find a DD who checks and uploads your shiny new package for you, this is called "sponsoring" an upload. Your name is still in the Maintainer: field of the package, so you are still responsible for keeping it in good order.
  3. Keep the package in shape, fix bugs, make new uploads with your sponsor.
  4. Decide whether you want to become a DD and do more work for Debian. If not, just continue with (3).
  5. So you want to become a DD. ;-) First thing you need is a DD who testifies for you, i.e. basically has the opinion that you are doing good work and would like you to become a DD. This is called "advocate". As they have to have some idea _what_ you did it is not sensible to just ask on debian-mentors for an advocate. It has to be somebody who has worked together with you, the DD who previously acted as your sponsor is a natural choice. Once you have an advocate you can start the NM-process.

What other resources are there for new and prospective Developers?

Apart from the debian-mentors mailing list, there are a wealth of useful places and documents which the aspiring developer can use to improve themselves:

  • Joe Nahmias suggests the #debian-mentors IRC channel on irc.debian.org (the OFTC network), for help with any packaging and other Debian-related problems you might be having.

  • The Developer's corner, which includes links to the Debian Policy, Developers' Reference, New Maintainer's Reference, and basically anything else that a DD or DD-to-be (that rhymes, hee hee!) might be interested in.

  • There is an article in IBM's developerWorks library entitled "Learn how to build easy-to-distribute packages for Debian users", which gives a softer introduction to the whole process.

  • The debian-women project has produced a Short BTS howto. They also run a One-on-one mentoring program for new developers, although it is a little dormant at the moment.

How do I adopt an existing package?

See http://www.debian.org/devel/wnpp/#howto-o.

What can I do to help Debian other than packaging?

Excellent question! Debian is a lot more than a great big collection of random packages. There's documentation to write and translate, bugs to fix, installers to test, and newbies to haras^H^H^H^H^H, uh, help.

If you write a language other than English fairly well (either because you're a native speaker or you've spent the time to learn) then consider helping out with translations. Everything in Debian needs to be translated, more or less - package descriptions, debconf questions, all of our documentation, etc. There are a lot of clever people involved there - be one of them! Translation work is mostly handled through http://www.debian.org/international/. Most translation projects can be found from there.

There are many thousand open bugs in Debian packages, ranging from the trivial to the critical. Consider looking in the Bug Tracking System for packages that you use often. Try and reproduce a bug, or find the cause of the bug and submit a patch to the bug listing, so that the maintainer can fix the bug. If a bug has one or more patches that haven't been applied in a long time, especially for more serious bugs, and the maintainer hasn't commented, consider bringing the package to the attention of the Quality Assurance team (debian-qa@lists.debian.org) so they can have a look at it. You can find Release Critical bugs for packages installed on your system (in case you might like to help fix them) by running the rc-alert script, which is available in the devscripts package.

Some maintainers have requested some help with their packages, by posting a Request For Help (RFH) on the Work-needing and Prospective Packages list (http://bugs.debian.org/wnpp). A list of current requests for help posted by other people is available from http://www.debian.org/devel/wnpp/help_requested, in case you're feeling helpful.

If you're interested in helping to fix a bug, there is a list of bugs that have been identified by package maintainers as fairly simple, and good to improve your skills on. For more information, see ?the QA group's wiki page about the tag.

Packaging

How do I make my first package?

Firstly, you may not necessarily have to package something from scratch.

Consider the benefits of co-maintenance. Instead of having to be out on your own, you get a pre-existing, presumably fairly well-maintained package, and someone to answer your questions.

There are quite a number of packages already in the Debian archives which are orphaned - that is, their previous maintainers have given up maintenance of the package for various reasons. The best option, especially for your first packaging attempt, is to adopt one of these orphans. There are also some packages which are still maintained, but which aren't really wanted by their maintainers any more (known as "RFA" packages, for "Request For Adoption").

The benefits of an RFA package are that you have at least one person who might be willing to sponsor your uploads, and you'll have someone familiar with the package who you can ask any questions you have with the packaging.

To find a package to adopt, look for bugs whose title starts with "O:" (for orphaned) or "RFA:" (for "Request for Adoption") under the WNPP bug list (or at the alternative interface). A more convenient method of finding interesting orphans is to install the devscripts package and run wnpp-alert. This will print out all the packages installed on the system you're running which are orphaned. Handy!

For "Request For Adoption" packages, you should contact the current maintainer and ask if they'd be willing to let you maintain it. Some maintainers may be unwilling to let their package go to an inexperienced maintainer for some reason. Please respect their judgement -- they usually have a good reason for not wanting to hand the package off to someone without experience. Also remember to ask the previous maintainer if they might be willing to sponsor your uploads.

Once you've selected a package to adopt, retitle the WNPP bug so it starts with "ITA:" (for Intent To Adopt) and start working on the package. Fix bugs, package new versions, and hunt for a sponsor for your new package. Remember to set the maintainer to you, and to close the WNPP bug in the changelog of your first upload.

Another place to look for packages is in packages which may not be listed as orphaned, but which are in a bad state. This is not something to take on lightly, as what constitutes "in a bad state" may not be immediately obvious. Nevertheless, if there's a program you use which you think is looking a bit shabby and might benefit from a new maintainer (you!) bring it to d-mentors or the debian-qa mailing list with your reasoning, and someone will try and help you out. Please Note: Don't go e-mailing maintainers with e-mails like "Your package looks unmaintained, I'm going to hijack your package". It helps nobody, and ensures that you will have at least one very unhappy Debian developer.

If you've got your eye on something new to package, there is a set procedure to follow. This is covered heavily elsewhere, including the New Maintainers' Guide, but basically:

  1. Pick something to package not already in the archive, and not listed as an ITP (Intent To Package) on the WNPP bugs page. If it's listed as RFP (Request For Package) then you'll be satisfying someone else's desire for a package, so you're doing extra-special good. <grin>

  2. If it's not already listed, file an ITP bug report against WNPP as detailed by section 5.1 of the developer's reference. If it's already listed as an RFP, retitle the bug as an ITP (see the BTS manipulation manual).

  3. Put a package together, built against a current version of sid. This simple sentence hides a multitude of sins -- it can be a complex process. Debian Policy and the Developers' Reference are the "bibles" of packaging, however the New Maintainers' Guide contains a more gentle introduction to the sport. The Debian Wiki also contains a basic How To Package For Debian guide, while the Debian-women project has produced a Packaging Tutorial.

  4. Provide a publically accessible place where all of the files relating to your package can be downloaded from. This includes both the source package (.orig.tar.gz, diff, and .dsc), and the corresponding binary package(s), including the .changes file (signed, preferably). There is a "pretend" upload queue at http://mentors.debian.net/ which can be used to host packages if you have nowhere better to put them.

  5. Request a sponsor from debian-mentors, and possibly other places.

  6. Keep your package maintained after the initial upload, by being responsive to bug reports and new upstream versions.

It is also recommended that you familiarise yourself early on with the Debian Developer's Reference and the Debian Policy, which are, respectively, the HOWTO and Do's and Don'ts (that's some ugly apostrophes) of packaging for Debian. You will need to know all about them if you apply to become a DD, so you should start studying now... <grin>

How do I add a new package to the archive?

(Thanks to Paul Wise)

  1. Get interested in a package by using or developing it.
  2. Discover that it isn't already available from the Debian archive.
  3. Check if it can be packaged (licence, etc) and if it is already being packaged by someone else (via ITPs on http://bugs.debian.org/wnpp)

  4. Review whether you can reasonably maintain this package. This includes the complexity of the package and your skill level, whether you're familiar with the programming language(s) used, and also whether upstream is active and you can expect reasonable support from them in bug-fixing and helping to handle bugs from Debian users.
  5. File an ITP (intent to package) bug using reportbug (or the bug reporting e-mail address) against the wnpp package. This is done to prevent duplication of work, and is an essential step.

  6. Create the package, getting help from the various resources listed in this FAQ and elsewhere.
  7. Install and test your package thoroughly. Ask on the debian-mentors mailing list for people to check your packaging for errors and common problems.

  8. If you're a DD already, you can just upload your package. Otherwise, upload your package somewhere that prospective sponsors can review it (such as http://mentors.debian.net/), and then ?find a sponsor to upload the package into the Debian archive for you.

  9. Once you get your package sponsored, please tell the debian-mentors mailing list if you asked for sponsorship there, so that other prospective sponsors don't waste time reviewing your package and getting it ready for upload when it's already been uploaded. That way they can go on and upload someone else's package. This goes for any other places you asked for sponsorship, like other lists, IRC channels, etc -- let everyone know you got a sponsor, so we don't duplicate effort.

How do I effectively keep track of my packaging changes?

At the basic level, it's a good idea to keep an archive of the completed source packages that get uploaded. Although there are services which keep a record of everything in the archive (such as http://snapshot.debian.net) there's the hassle of having to go and retrieve your packages from there, and there's no guarantee that external services will always have old copies of your package available. A local copy is just that much easier and more reliable to work with. The debdiff and interdiff programs (in the devscripts and patchutils packages) can help you look at the differences between package versions.

Getting into a more fine-grained approach, consider using a revision control system to store all of the changes you make to your packages. There are *-buildpackage scripts for several of the more popular revision control systems (cvs, svn, darcs, and arch), which will retrieve your package out of revision control and build it for you automatically.

Getting the right workflow with your revision control system can be tricky. Manoj Srivastava has a page on managing your packages using Arch at http://arch.debian.org/arch/private/srivasta/.

What is the difference between a native Debian package and a non-native package?

(From Matthijs Mohlmann, with additions by Thijs Kinkhorst)

  1. Non-Native Debian Package

    • A non-native debian source package contains a dsc, diff.gz and an orig.tar.gz file.

      The version for a non-native Debian package looks like ?UpstreamVersion-?DebianVersion for example: 2.8-1. In the diff.gz: These are the modifications you made to the package. It contains the debian directory and the modifications you made to the source tree, if any. In the orig.tar.gz: This is the upstream tarball. You should very rarely make changes to this file, and you should never ever make changes unless you explicitly understand why you are making them. All changes should normally go into the diff.gz.

  2. Native Debian Package

    • The Version number for a debian native package is only the version, it doesn't have a Debian revision number, it looks like: 2.8. A native package contains only a dsc and a tar.gz file. The disadvantage of a native package is that there is no clear separation between "upstream code" and "Debian changes". This means that it is harder to separate out patches that should be sent upstream, and unnecessarily muddies the waters of who is responsible for what. Additionally, a native package requires a whole new .tar.gz to be created whenever there are packaging changes (which wastes bandwidth and mirror space), while a non-native package only requires the upload of a new .diff.gz, which is typically much smaller.

      Native debian packages are often accidentally built when upstream tarball (.orig.tar.gz) is named incorrectly. It should always be named <sourcepkg>_<upstreamversion>.orig.tar.gz.

  3. When to use a native vs a non-native debian package

    • You should only use a native Debian package when it is clear that the package would only ever be of use in Debian. Even if the software is currently only available in Debian, if someone could reasonably use the software on another distribution or on another operating system, then the package should be non-native. A few examples of normal packages are: libc6, apache, phpmyadmin. But lintian, dpkg and some other tools are purely developed for debian, and make no sense being released in another distribution.

What's wrong with upstream shipping a debian/ directory?

There are cases where upstream ships a tarball which already contains a debian directory. This is undesirable, even if you're upstream yourself or can commit there. Keep the released tarballs (used as .orig.tar.gz) and the debian directory separated.

The problem is that at some point, upstream's debian directory will deviate from the one in the Debian package -- because the maintainer changes, the directory was already outdated, or someone does an NMU or a security upload. Because it was The .diff.gz will now be a diff between the two debian dirs, which is very confusing.

The Debian package format is designed to keep upstream and Debian-specific neatly separated into orig.tar.gz and .diff.gz. Putting the debian dir in the .orig.tar.gz confuses this.

If upstream has a debian directory in their releases, you should contact them and ask if they can remove the debian/ directory from their tarball releases. There's no need to remove the debian directory from their revision control system (although if it's out of date they may decide to do so anyway), but at the very least the directory shouldn't appear in releases. If you are upstream yourself, well, you can ask yourself to do it.

What does dfsg in the package name mean?

dfsg is a conventional way of naming a package, when upstream software was repackaged, because it contains some non-free elements. The changes should be documented in README.Debian-source. The recommended way of naming a package with the 'dfsg' bit is:

  • <UPSTREAM VER>+dfsg-<DEBIAN VER>

For example: I have packaged foobar application which has just released version 1.2.3. Normally the package name would be: abc_1.2.3-1 - and it was packaged as such. I have then discovered that the package contains some files that can not be distributed with the main Debian repository. I have removed them from source package (from .orig.tar.gz) and released new package: abc_1.2.3+dfsg-1. Later on, I have found even more files that should be removed. I did that and released abc_1.2.3+dfsg2-1.

What's a sponsor, why do I want one, and how do I get one?

A sponsor is a registered Debian Developer (DD) who takes the packages of a non-DD and uploads them to the archive on the non-DD's behalf. The sponsor is required to check the quality of the package, that there are no show-stopping bugs in it, and that it is unlikely to harm either the Debian infrastructure during build, nor user's systems when in use.

The sponsor needs to do all of this because they are ultimately responsible for what gets uploaded by them into the archive.

You need a sponsor because, as a non-DD, you do not have the ability to upload packages directly into the Debian archive. So, you need to route your packages through a sponsoring DD so they can be properly signed and uploaded.

The presence of the sponsor doesn't mean you can neglect your maintainership duties. You are listed as the maintainer - it's your reputation on the line too. You are expected to keep a handle on bugs and new upstream versions, feed information from Debian users back to upstream, and generally uphold Debian's reputation. If you "dump" poor quality packages on sponsors, or do not maintain your packages well, do not expect to get many people willing to sponsor you.

<yoda>Scared? You will be...</yoda>

What's the difference between a sponsor and an advocate?

A sponsor is any Debian Developer willing to upload packages on your behalf into the Debian archive. You may have multiple people who act as sponsors for your packages - different people for different types of packages, or maybe you change sponsors over time, or rotate between a few (with the knowledge of all of them) to spread the load.

An advocate is a Debian Developer who has worked with you in your capacity as a contributor to Debian, and believes you would be an asset to Debian. When you are ready to apply for New Maintainership, the advocate makes a statement to the effect that they believe you would be a worthwhile addition to Debian, and your application moves forward. Without an advocate, your application cannot proceed.

There is no point asking for an advocate on debian-mentors or any other open mailing list. No developer should be willing to advocate for you without knowing something about you.

So how do I get an advocate then?

Which Debian Developers have you done Debian-related work with? Typically, if you're ready for NM, you should have worked with at least one, if not several. Ask them. If you've done good work, they should be more than happy to say that to the Front Desk via an advocacy. Get them to ask on debian-mentors if they're not sure exactly what advocacy is, when it should be done, and how.

One of your sponsors can be your advocate, and this would probably be the most common way of obtaining an advocate. But if you've had significant contact with any other DD, you can consider asking them.

How do I get a sponsor for my package?

First thing - there is no guarantee that anyone will sponsor your package. It all depends on the interest level and time available from any DD who might sponsor you.

The general rule is to make a request on debian-mentors for a sponsor. Put "RFS:" (Request For Sponsor) at the beginning of the subject of your message. Things to put in the message are:

  1. Name of the package;
  2. The licence the package is provided under;
  3. Short and long descriptions of the package; and
  4. Where the package can be obtained from (either via FTP/HTTP or by e-mailing someone). If you have nowhere to host files yourself, you can make use of the mentors.debian.net service.

Messages without all this information are far more likely to be ignored.

Your message to -mentors is like an ad for your package. It's likely to be the only thing that prospective sponsors will judge your package on. You can have all the extra URLs you like in there where sponsors can get more information, but unless your initial message piques their interest, they'll never look at them.

So, tell us what exactly your package does, and why it should be in Debian. If there is already a program that does a similar thing, say why your one is better. Put a little "hot spice" in there to hold people's interest. in other words, think like an advertising executive. Just remember to wash the slime off afterward.

You'll notice that one of the things to have is where the package can be downloaded from. That implies that you've packaged it already. Don't bother asking for a sponsor until you've got packages (more-or-less) ready to download.

Sponsoring a package takes a lot more than just downloading it from your website and uploading it to Debian. The prospective sponsor needs to check over the quality of the packaging and ensure that it meets Debian's quality standards before uploading it. For this reason, you need to provide all of the parts which would be needed for a full upload (.changes, .dsc, .orig.tar.gz, .diff.gz, and .deb(s)). Also, it may take a few days/weeks to get the whole package checked over, and the sponsor might want to talk to you a bit, just to find out what sort of a person you are.

Think of all this as a mini-NM check - which is, basically, what it is.

But why should I waste time packaging if there's no guarantee it's going to be uploaded?

You shouldn't be generating a first package "just to get it in debian". The archive is already well-stocked with poorly-maintained vanity packages. A first package, especially, should be something that you really want to see in Debian but which hasn't been uploaded already for whatever reason. That personal interest will help keep your interest levels up.

It is important to remember that an upload isn't a one-off thing - you're responsible for that package forevermore, unless you request it's removal or find another suitably qualified person to maintain it for you. It's like having a child - a big responsibility.

Where else can I get a sponsor?

debian-mentors isn't the only place where you can get a sponsor. In general, you're more likely to get a sponsor who is actually interested in what you've packaged, but doesn't have time to package it themselves. So, if there's a list dedicated to your "niche market", Cc: the RFS there. For instance, if you're packaging Yet Another Perl Module, try a Cc: to debian-perl@lists.debian.org. If it's YAPython Module, d-python@l.d.o. Apache module? d-apache@lists.debian.org. Something legal-related? d-lex@l.d.o. Something for kids? d-edu@l.d.o. Getting the picture yet?

Also, if you're packaging something in a particular technological line, you'll probably want to be subscribed to the relevant speciality mailing list anyway, so you can ask technology-specific questions to the people who know all about it.

What happens if I can't find a sponsor?

First off, don't panic. Not having your package in Debian immediately isn't the end of the world.

Solicit comments on the packaging on IRC and d-mentors. Don't just mention the package name, also provide (at least) the brief description. Typically a developer is more likely to sponsor something they might be interested in using, or which they recognise there might be a need for. Just the package name doesn't really convey the sort of information needed to make that call.

Sometimes RFS' fall through the cracks, so continue updating the package. Mention the package on d-mentors every month or two; people come and go, and their available time varies, so a later mention may catch someone who couldn't help you before.

Try to get it uploaded to Ubuntu's REVU, you will probably get lots of good comments on your package in the process, and perhaps someone from Utnubu will notice that your package was uploaded to Ubuntu and offer to sponsor it for you.

Meet some Debian folk in your area or at DebConf and bribe them to sponsor you :) It's a lot easier for someone to commit some time to helping you if they've got a face and real personality to put to the e-mail address (plus it's a great excuse to get some keysigning action happening).

Fix lots of bugs, get involved in doing QA work, perhaps you will get to know a DD well enough that they will sponsor you.

For Sponsors...

Who can sponsor a package?

Any Debian Developer with a key in the keyring can sponsor a package on behalf of another maintainer. There is no special "register" of sponsors. Note that sponsorship is rarely a one-off event; you need to be able to handle regular uploads on behalf of your "sponsee". If you can only do a once-off upload, make your prospective sponsee aware of this up-front, and try to find someone else who will be able to continue the sponsorship process in the future if required.

What is the process for sponsoring a package?

You should first, of course, find a package to sponsor. http://mentors.debian.net/, the d-mentors list and IRC channel, are all good places to find packages.

You need to get the *source* package from your sponsee. That is, the .dsc, .orig.tar.gz, and .diff.gz. You should check the package over carefully, perhaps with reference to Mathew Palmer's sponsorship checklist. If there are problems, provide constructive feedback to the sponsee. Work with them to make the package the best it can be. Build the package on your system, try it out -- does it install/remove properly, does the program run, is it policy compliant? All of the things you're supposed to do for your own packages. Yes, it's a lot of work, but you're responsible for any crud that lands in the archive under your key.

Immediately before upload, rebuild the package in a clean sid chroot, sign the .changes/.dsc file with your key, and then make a normal upload. Make sure your name isn't in the Maintainer: or Changed-By: headers of the .changes file. You can ensure this by either using the -k option to dpkg-buildpackage/debuild, or building without signing (-uc -us) and then using debsign to later sign the .changes file (which will sign the .dsc as part of the process). Do not use the -m or -e flags to dpkg-buildpackage/debuild, as that actually changes the maintainer/uploader information in the .changes/.dsc, which is most certainly not what you want.

Whatever you do, do *not* simply re-sign and upload the sponsee's .dsc/.changes, or (worse!) just upload what they send you (since it won't be properly signed).

What about recurring sponsorship of the same package?

You should work out a mutually-agreeable way for your sponsee to contact you to upload new versions of their package. Upload to http://mentors.debian.net/ (with notification to you, the sponsor) is a good way to go, especially if the sponsee doesn't have web space of their own.

You should do appropriate checks of each new revision your sponsee provides. The debdiff tool (from the devscripts package) is excellent for getting an overview of what has changed between Debian revisions.

What if I upload a package, and then my mentee disappears?

As a Debian developer, it might be scary to upload a package for someone, only to have them perhaps disappear. Don't fret; you don't have to take responsibility for it if your mentee vanishes.

If the mentee disappears, just follow the same procedure as if a Developer went missing-in-action: do a non-maintainer upload of the package, assigning it to debian-qa, and make it available for adoption (or eventually orphanage).

Having said that, this does create some extra work for people who decide to work on QA. It's good to make sure the package that you upload is of decent quality and not a duplicate of an existing package.

To summarize, maintainers and packages enter and exit Debian; it's part of a life cycle. It's okay to upload mentees' packages knowing that you risk going through an orphaning/adoption process later.

What resources are there for sponsors and prospective sponsors?

  • The http://mentors.debian.net/ website;

  • The debian-mentors mailing list;
  • The #debian-mentors IRC channel on irc.debian.org;

  • Several sponsorship checklists (none of the lists are either exhaustive or definitive);

  • A better checklist (from the gatekeepers of the archive) is also available;

  • Consider setting up a "sponsoring" alias for you and your sponsee, by creating a file in your home directory on master.debian.org called .forward-sponsoring-<jbloggs> containing your e-mail address and the address of your sponsee separated by commas (see existing entries on master). This will create a mail alias, <yourname>-sponsoring-<jbloggs>, which will send mail to both you and your sponsee. Handy!


Originally created and maintained by Mathew Palmer at http://people.debian.org/~mpalmer/debian-mentors_FAQ.html

Copyright © 2003,2004,2005,2006,2007 Matthew Palmer. Released under the terms of the GNU General Public License version 2.


CategoryDebianDevelopment