Mattia's Rules For Sponsorships

Mattia Rizzolo <mattia@debian.org>

I'm generally happy to sponsor everything, from new packages to NMUs.

Though be advised I'm pretty picky, and don't get mad if I refuse to sponsor your package because the package is IMHO just crap, or reply to you with a huge list of stuff to be fixed. ;)

Please keep in mind I generally refuse to sponsor new packages (ITPs) from people I've never heard of before, as I don't trust you to stick around and continue the maintenance; clearly this doesn't hold if you are already involved in Debian, or you have some recorded track of contributions in the wider free software world.

Contact

In order of preference:

email to mattia@debian.org
IRC (mapreri on OFTC and Libera)
real life (seriously, if you happen to be nearby, try a shot!)

In some occasion I may redirect you somewhere else.

If this is the first time I've ever heard about you please start by writing an email: you can always move to IRC pretty quickly, and most probably I'll do it myself. If you have a history of sponsorship by me then just reaching out on IRC works great.

How To Provide The Source Package

I prefer a git repository, with the standard gbp layout with the full sources in the repository. I want at least the tags to be GPG signed, gbp will do it for you if you have sign-tag = True in your ~/.gbp.conf; if that won't be the case I'll be forced to look through ~all the files and the history, compare with what was actually uploaded and in general do more work that I'd avoid if there was a gpg-signed tag I can trust. Please try to keep that repository in Debian infrastructure, like salsa.debian.org. If you don't use git don't bother with other VCSes, I don't care.

I can also review and sponsor packages which are not maintained in a VCS, for them please provide me a link to a signed .dsc that I can pass to dget(1).

Guidelines

Maintainer Uploads

If you maintain the package you ask sponsorship for, sorry but I'm super picky! ;) There are just about no exception to the followings:

No trailing whitespaces. In vim it's super easy: :%s/\s\+$//.
Standards-Version up-to-date.
No open bugs from the Reproducible Builds and rebootstrap/cross-builds teams.
Super-verbose debian/changelog.

Really nice to have (you'll need to explain why your package fails on those):

Debhelper compat level 13 and use the dh sequencer (and use debhelper-compat, not debian/compat).
Lintian clean (I mean, also all of informational, pedantic, experimental tags; but lintian is being too noisy recently, so if you believe it's correct the way it is, just mention it).
- In the past years lintian got much noiser than it used to be, so I'm not as strict on this as I used to be, but I'll still be reading what lintian has to say.

Non-Maintainer Uploads

If you are asking sponsorship for a NMU you'll have some leeway compared to the above, surely you can't rewrite debian/rules just for fun! Yet, I expect some QA work on any upload, so I'd prefer if you could fix also some other things other than just the bug you're chasing.

Furthermore:

you must be fixing an open bug, and either:
- the fix is really really really critical to be fixed right now (really?)
- the maintainer is MIA enough (I'll check it)
- the maintainer gave a public green light
- the package is in the Low Threshold NMU list
- the bug is severity >= important and there has been no reply from the maintainer in the last 2 weeks.
keep in mind I'll most probably upload to DELAYED/10 or DELAYED/5.

Things I Care About

Following a list of stuff I'd like to see on any package I review. If your package does not comply to things in this list most probably I'm going to ask you why.

use debhelper(7), no cdbs, nor a manual thing with no helpers
use the dh(1) sequencer. There is nearly to zero reasons to not use it, it just saves everybody's time
source format 3.0, 1.0 is old and have no advantages whatsoever over 3.0, it just causes unecessaries headaches
debian/copyright should use copyright-format 1.0; I find non DEP-5 copyrights to usually be incomplete, and most of the times are also harder to read
the clean target of your d/rules should restore the packaging directory to the same state as it was after unpacking: I don't want to fiddle with git to restore deleted files, etc.
I find most of debian/dirs and debian/*.dirs useless, please check them again. And again. If they are still needed please fix the build system.
enable the hardening build flags: export DEB_BUILD_MAINT_OPTIONS = hardening=+all
if this is a Python thing, use pybuild(1)
if this is a Python thing, build for python3, and drop python2 support.
if your package is repacked please include a Files-Excluded field in d/copyright with the list of files removed; and maybe also a debian/README.source file
there should be no Ubuntu delta, and if there is I want you to explain why you can't import it
don't build manual debug packages, nowadays we have the automatic ones
keep your control file nicely sorted with wrap-and-sort (I like -ast)

Good Git Habits I Appreciate

GPG sign all the tags (very recommended)
GPG sign all the commits (commit.gpgsign true; not nearly as recomended as the above)
the remote HEAD points to the packaging branch
debian/gbp.conf is provided in any case a non-standard layout is wanted (including non-standard tags format)
a pristine-tar branch is included
there are tags for every upload done and every upstream release ever imported