Thanks for the feedback!

Please follow CONTRIBUTING.md [...]

What part of CONTRIBUTING.md did I not follow? (Honest question. I just read it again and can't determine where I went afoul of it.)

[...] and manual#submitting-changes-making-patches and squash the commits.

This is a lot of small bumps, I would just compile into one

python3Packages.python-gitlab: 1.15.0 -> 2.2.0

Does that manual section mandate squashing of all commits? The only rule towards that direction seems to be

• If you have commits pkg-name: oh, forgot to insert whitespace: squash commits in this case. Use git rebase -i.

None of my commits here are of "oh, forgot to insert whitespace" nature, as far as I can tell.

That manual section also says:

• Make commits of logical units.

That's what I tried to do here. Note that I didn't make separate commits for all versions since 1.15.0. My reasons for the commits are as follows:

• be60e99 re-format with nixfmt: Unrelated to the version bumps. Would result in confusing / misleading change reasons being shown by git blame if it'd be included in a version bump commit.
• a27308cf473a2d078abf41c16ea225a366815fb9 1.15.0 -> 2.0.0: Major release, this bump is the reason for dropping six and for disabling on Python < 3.6
• 7cceb71ed740831ed7f0a5190969a4f5e2d3b9f1 2.0.0 -> 2.0.1: Latest patch release of 2.0 minor release group
• 548bb89f8e78c188f0eb9981087c8fb98b4b470f 2.0.1 -> 2.1.2: Latest patch release of 2.1 minor release group (Note that I skipped over 2.1.0 and 2.1.1)
• a7706508276dbb85f0e562a729c18ce755b6d4f9 2.1.2 -> 2.2.0: (Current) latest patch release of 2.2 minor release group

Yes, these are many bumps, but I think having them in the history is worthwhile. If you maintain that they are too many, I'd like to at least preserve be60e99 & a27308cf473a2d078abf41c16ea225a366815fb9 (and squash 7cceb71ed740831ed7f0a5190969a4f5e2d3b9f1, 548bb89f8e78c188f0eb9981087c8fb98b4b470f and a7706508276dbb85f0e562a729c18ce755b6d4f9 to one single commit, resulting in a total of 3 commits), unless you insist they be all squashed into only one commit.

Does 3 commits sound good to you?

Either

• re-format with nixfmt be60e99
• 1.15.0 -> 2.0.0 a27308cf473a2d078abf41c16ea225a366815fb9
• 2.0.0 -> 2.2.0 7cceb71ed740831ed7f0a5190969a4f5e2d3b9f1 + 548bb89f8e78c188f0eb9981087c8fb98b4b470f + a7706508276dbb85f0e562a729c18ce755b6d4f9 squashed

or

• re-format with nixfmt be60e99
• 1.15.0 -> 2.0.1 a27308cf473a2d078abf41c16ea225a366815fb9 + 7cceb71ed740831ed7f0a5190969a4f5e2d3b9f1 squashed
• 2.0.1 -> 2.2.0 548bb89f8e78c188f0eb9981087c8fb98b4b470f + a7706508276dbb85f0e562a729c18ce755b6d4f9 squashed

make most sense, if not all 5 commits shall be preserved.

From the perspective of the master branch, I think it makes more sense to just do all the bumps in one go, because the individual package bumps never existed. But that's just me

From the perspective of the master branch, I think it makes more sense to just do all the bumps in one go, because the individual package bumps never existed.

Alright, I've squashed the four version bump commits into one, but left the re-format commit as-is.

But that's just me

Not quite sure what to make of that. If you require changes for an approving review, please give actionable feedback. If however the PR just isn't to your best liking, but you find it objectively acceptable, please state that clearly.

Not quite sure what to make of that. If you require changes for an approving review, please give actionable feedback. If however the PR just isn't to your best liking, but you find it objectively acceptable, please state that clearly.

To me, you're doing a version bump, if you have a series of 4 version bumps, why not collapse it into a single version bump? If there was a regression in this package, then having the many version bumps doesn't really help, because you are trying to triage regressions from master. So having an intermediate commit, which never had a release on that package, seems to add noise when doing a git bisect.