Adopting a package
Adopting a package can be quite scary and overwhelming at first, but it's not actually that difficult. This HOWTO aims at providing a step-by-step approach in order to ease getting involved for those who'd like to help, but don't exactly know how.
Finding the right package
So you want to adopt a package, eh? You're not sure which package to adopt though? Then I hope these hints will help you find the right package.
Obviously it doesn't make much sense to adopt a package that already has a maintainer. Packages that can be adopted are those whose previous maintainer has stopped maintaining or will do so for some reason. These packages are said to be up for adoption.
Packages that are up for adoption usually come in two flavors: a) the previous maintainer has lost interest in them (orphaned packages) or b) the current maintainer files a RFA (request for adoption), stating that they don't plan to continue maintaining the package.
Packages marked RFA can be found here. These are the ones that you should look at first. RFA packages are usually in a very good state, and since the current maintainer thinks the package worth to be adopted, they are a pretty safe bet.
A list of orphaned packages can be found here. That list is usually quite long, which is pretty good for our current goal, because it gives you a broader range to choose from.
First you should search through the lists and look for packages that you use. Maintaining a package that you actually use will make it easier for you to keep up the good work. In case you don't find a package that you're using in the lists, try looking for something that looks interesting, something out of an area which is of special interest to you.
Note however that there are also packages that might be better off if removed from Debian. Such packages are not easy to spot, but a good indication is if the package was orphaned a long time ago. Other criteria can be found on the Debian Quality Assurance page.
There is no general step-by-step approach to finding a package to adopt, so you might have to wait a couple of days (or even weeks) until an interesting package pops up on the list. In the meantime you could look around and help in other areas where help is needed.
So you've been spending a lot of time searching the long list of orphaned packages, and finally found something you're interested in? Very good!
Before proceeding, you should take a closer look at the list of open bug reports for the package. The list is available here.
Skim through the list (if there are no open bugs, go for it!) and try to judge whether you might be able to fix some of them. This can be a pretty tough call and the best way to find out is by actually *trying* to fix them. You don't necessarily have to do that right now, but it might give you a pretty good idea about the bugs (sometimes, bugs look trivial from their description, but turn out to be really tough to fix).
Being able to tackle bugs in a package is essential for a maintainer, since you'll be the primary contact for future bug reports. No need to run away screaming now though. You can always ask for help if you're not able to solve all problems yourself. After all there is a huge community that will be glad to help.
You should also check upstream for new versions, or whether the program is still being developed upstream at all. `Upstream' designates the original author(s) of the software. It is usually not a good sign if a package has no active upstream source. A good idea would be to contact the upstream author and tell them about your intent to adopt. They might already be aware of the fact that their package is maintained for Debian, but it is polite to introduce yourself, in case you will continue working on the package.
If this is the first package you intend to adopt (and chances are it is, otherwise you would probably not be reading this HOWTO) you might be a bit scared and/or nervous right now. This is perfectly normal though. After all, you're about to be taking on quite a responsibility (in case you're neither scared nor nervous, good for you).
Stating your intentions
The following will take you through the process of stating your ITA (intent to adopt) by sending a mail to the BTS.
The ITA mail should be sent to
nnn is the number of the bug report which
orphaned the package) and Cc'ed to
firstname.lastname@example.org is standard procedure,
and you might already be familiar with it from submitting previous
bug reports or follow-ups. Cc'ing
email@example.com is necessary because you will
want to change the status of the bug. Changing the bug status is
required in order to show that you are working on the problem.
Furthermore, you want to make yourself the owner of the bug, as a
first step to becoming the package's new maintained (how this can
be accomplished will be explained below).
The subject line should conform to normal email rules. An example could look like the following:
Subject: I Intend to Adopt <package-name>
The mail body should start with the following lines:
retitle nnn ITA: <package> -- <description> owner nnn ! thanks
This will change the title of the bug report to reflect your intentions on adopting the package. Obviously you should specify the package name and a short description, or else nobody will know what it is that you're trying to achieve.
The second line will make you the new owner of this bug. As owner you will automatically receive all follow-ups by email. You will also be considered to be in charge of fixing the bug (i.e. packaging, uploading, ...). Note that the exclamation mark (!) is a shortcut for inserting the email address that you're sending from as your maintainer address. If you would rather use a different address, simply substitute it for the exclamation mark.
The third line terminates processing by the control server
firstname.lastname@example.org). Subsequent lines can and
should be used to give some details about your reasons for adopting
the package, or the progress you've made on fixing outstanding bugs
(you did try to fix those, didn't you?).
Once you've sent the mail, it will take a couple of minutes to be processed by the control server and for you to receive confirmation. The package is now marked as being adopted by you, so you should get started on fixing those bugs.
Where to go from here
Now that you've finished adopting the package, you should start working on fixing the outstanding bugs for the package. I know I'm being repetitive, but fixing bugs is really important. Now would be the perfect time to have a look at the Debian New Maintainers' Guide which has all the information you'll ever need concerning packaging. You might also want to take a look at the Debian Developer's Reference and the Debian Policy.
Once your new package is ready, you should look for a sponsor to upload the package for you, because unless you are a Debian Developer, you won't be allowed to. The sponsor will take a look at the package, to see if there is anything that you might have overlooked and, if satisfied, will organize a non-maintainer upload (NMU).
If things don't work out
Should you decide at some point that you don't have the time to go
through with the adoption process, or you are not able to fix
outstanding bugs, you should send another mail to
email@example.com (Cc'ing to
firstname.lastname@example.org). The subject should contain
Subject: I cancel my Intent to Adopt <package>
The body should contain something along the lines of:
retitle nnn O: <package> -- <description> noowner nnn thanks
Which will retitle the bug report and remove you as current owner of the bug. As before, you should give a reason as to why you stopped working on the package. Provide all the information you think might be useful to others when attempting to adopt the same package. That way, your effort will not have been in vain.
That's about it, that's all I have. If you have any comments or suggestions, feel free to drop me a mail.