Bump.

This pull request has been mentioned on Nix community. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review-may-2019/3032/42

Good bot.

This pull request has been mentioned on Nix community. There might be relevant details there:

https://discourse.nixos.org/t/join-the-package-maintainer-team/3751/5

Thank you! As a general question, I was wondering, is it usually desired by maintainers that packages related PRs will consist of a single commit? @worldofpeace has asked me in the past to squash changes and since then I've always made changes with a git commit --amend --no-edit and pushed with --force.

It depends on context (but also a lot on the reviewer's preferences). My opinion is that every commit should do one thing, but there is no reason to maintain all histories within a PR. So in this case, the "one thing" is initializing a package. Nobody gains any information from the additional commits incorporating my nitpicks (and they don't have the appropriate naming scheme anyway), so I've used github's squash-and-merge feature.

But if, for example, this was the first package you maintain you should have one commit adding yourself to the maintainers list and then a separate commit init'ing the package (using the maintainers entry). Or if you're fixing a broken package and while you're at it also updating it to the latest version, you could have two commits: package: fix build and package: old_version -> new_version.

Basically two rules of thumb:

• you shouldn't need to use the word "and" in the commit message
• ask yourself if it could ever be useful to have these as separate commits (for example I might want to revert the init of a package, but that shouldn't revert the addition to the maintainers list as well)

And remember that these are rules of thumb and if its easier to just do everything in one commit, sometimes its just not worth to spend the time and dis-entangle everything ;)