Sponsoring guidelines

Intro

I've tried to write a document about what I expect from my sponsorees. I wrote them so that they are clear from day-0 of my sponsoring, and so that my standards are clear too.

Those are my standards and are (did I said sadly ?) not the default Debian standards (yet ?). Other sponsors may have different sets of ones, so go see them if you don't like what I expect from you *grin*.

Note: yes I did inspired myself from Matthew Palmer sponsoring guidelines.

Pre-conditions

• You must be intending to join the Debian project at some point. Sponsorship is a step toward becoming a full DD. It's a mentoring stage, not an upload facilitator. Though, you don't need to be in NM yet. I just expect that when we've worked together a bit, you will enter it.
• GPG key: I don't expect it to be signed into the Debian web of trust yet, though I need that a short enough trust path exists between us. Though remember that will be a requirement for NM.
• You must understand Debian philosophy: that does not only means the DFSG, but also that Debian is about quality rather than quantity. Meaning that I will be very picky about your packages, but you'll see, it's only painful for the first upload of a package.
• You don't need to know everything yet: though I do expect that you have read the Debian Policy and the Developer's Reference, and know what it's about.
• I expect you to want to learn: you may be a truly brilliant genius, but you won't know everything from day one. I expect you to listen to my remarks and critics, and to remember what I already explained once.
• I expect you to be able and to want to work in a team: co-maintaining is great, teams are vital to debian.

The Procedure

Usual things

• If I don't sponsor you yet: don't send me .dsc URLs, rather go through debian-mentors@ or try to contact me on IRC so that we can discuss. I'm usually on #debian-devel, #debian-mentors and #debian-devel-fr on irc.debian.org (OFTC).
• If I already am (one of) your sponsor(s): you can send me .dsc to NEW packages without prior consent, I will usually sponsor them as well.
• Never send a package by mail. rather use any http or ftp web space you can have access to (mentors.debian.net is here if you have none), and only send me URLs to your .dsc files, so that I can dget them. Doing this by mail or in an IRC query is fine.
• Packaging Techniques (or “can I use cdbs ?”): I have absolutely nothing against you using cdbs.
  — O'RLY ?
  — YA'RLY !
  *Though*, cdbs is a subtle tool, and I expect you to be able to understand cdbs sources, as it's often there that you will have to find answers. That means that you need to:
  • have good GNU Make skills (as cdbs uses GNU Make constructions a lot);
  • understand how the underlying dh_* commands work, and what they do, meaning that you must understand debhelper too.
• Under (almost) no circumstances have a diff.gz that touches the upstream sources. Well, there must be an exceptions: I tolerate it when it's because you *need* to patch the build system (Including relibtoolization). Those patches are quite hard to deal with from debian/patches, so if you get around it, that's better, else I won't bother you with that. For anything else, please use a patching system (quilt is great, but you can use whatever you like or are used too).

What will I do and expect

• I expect your packages to be lintian clean. But never ever use an override without discussing it with me first. E.g. overrides on the “missing manpage” is a gross mistake, don't do it. Overrides have to be used when lintian is complaining about a problem that isn't one, or cannot be avoided in your package (the latter is rare, don't be too tempted).
• I expect your packages to build in a clean chroot. I usually uses pbuilder, and it's where the package I upload will be built. Pbuilder is easy to setup, please spare us both time in testing your builds properly.
• For NEW packages or new upstream revisions:
  • I will do a full check, including reading the debian/copyright. This is the most tedious part of packaging, and I expect it to be excellent. (here are some good examples from previous sponsorees: [0] [1] [2]. Those two posts are must-read: Peter Palfrader's mail, Andrew Suffield's mail).
  • You must file an ITP: it is important that your upload closes an ITP, so that the rest of the world knows you're working on it. It may attract co-maintainers too.
  • I will check the package has an interest: I wont package trivial things, that are a single .c file or a 10 liner in perl. I believe those packages bloat the archive, have seldom users, and their users can often build them themselves easily. A package must add value to the archive, not dilute it.
  • Check it's the same tarball as upstream's: if you need to prune the upstream tarball to meet DFSG, you must provide the pruning script, putting it somewhere in debian/ is a good idea.
• For new revisions:
  • I will check the debdiff with the previous version: expect questions for any diff chunk that is not explained in the changelog. Disk space is cheap, please have decent changelogs about everything you do. Not every changelog entry needs to close a BTS Bug, but every significant change should be documented.
• What I won't do:
  • Test the software extensively: I mean, it's up to you, you will have to care about it as the Maintainer of the package. I will try to spot obvious breakages, and big problems, but related to the software in itself, you're on your own. Though if it appears you're not doing it, that may end up our relationship.
  • Test every intermediate upgrades: piuparts is here for it, it's very time consuming, and such bugs end up quite fast in the BTS anyway. Again, if it's obvious to me you never check upgrades, bad things will happen :)

Final word

I expect sponsorship to be exciting and fun. For both of us. I enjoy a lot to teach things, and have liked to sponsor people so far a lot. (and it's way easier to criticize one's work than his own *grin*). My goal is that you get skilled enough so that NM becomes a simple formality.