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...