Sponsor Checklist for Sergio Durigan Junior


I find sponsoring packages really fun! I like reading how others solved a packaging problem, and I take pride in seeing the progress that happens after you sponsor a few packages for the same person. I think every DD should dedicate some time to sponsor packages and help the community grow.

Contacting me

If you'd like to request a sponsorship, the best way to reach me is by email:

You can also try pinging me on IRC (sergiodj on OFTC and Freenode), but please don't expect a prompt reply.

I am usually open to sponsor packages for anyone, but if you have never talked to me before, please take a moment to introduce yourself before asking for sponsorship. Bonus points if you have contributed to other packages in Debian or to other Free Software projects elsewhere.

My sponsorship rules

I am happy to sponsor almost any package, but beware: I am picky when reviewing sponsorship requests. I believe the sponsoree will benefit greatly if I offer him the opportunity to correct even the smallest mistakes I noticed during the review.

A non-exhaustive list of things that I check during the review follows:

Use git to maintain your package

Nowadays, there is no more excuse to not use git to maintain your package.

If you're proposing a change to a package that you don't maintain, and this package is not maintained in git, then I'm fine if you provide me with a .dsc file. I will probably ask if you'd like to create a repository for the package in salsa (using gbp import-dscs --debsnap); feel free to refuse if you don't want to.

Use salsa.debian.org to host your git repository

I expect you to use https://salsa.debian.org to host your git repository. If you don't want to use salsa, then I expect you to give me a good reason not to. You are free to choose another Free Software-friendly git forge, like https://pagure.io. Yes, this means that I do not consider github to be a valid alternative in this case.

Use gbp (git-buildpackage)

I expect you to use gbp, and I expect to find the usual gbp layout in the repository (i.e., pristine-tar and upstream branches). You should sign the tags you create; you can do that by adding the following line to your ~/.gbp.conf:

sign-tags = True

Use the latest debhelper-compat level and the dh sequencer

If it's a new package, or if it's a package you maintain, I expect you to use the latest debhelper-compat level and the dh sequencer. Really, there is virtually no excuse not to do that.

If you're proposing an NMU/QA upload and the package doesn't use these things, then I won't make you rewrite everything.

Use the latest Standards-Version

And make sure that you actually check what has changed in the Standards-Version before bumping it!

No trailing whitespaces; newlines at the end of each file

Trailing whitespaces should be easy to catch because git diff colours them red. git will also inform you when there is no newline at the end of a file. Please fix these.

To be continued...