Am I the only one troubled with the fact that the most important third-party library in the Python ecosystem has a git history that looks like that[0]?
This seems like a fitting snippet in relation to a messy git history (full of README changes).
"But none of the money was available to fulfill those commitments; instead, he was going to wait for me to implement the new features for him, and then he needed the entire $28k to pay for writing documentation for my features."
From the headline I assumed Kenneth "donated" it to get away from all the (entirely self-caused) drama and lay low to rebuild his reputation.
Instead I see he is still on the project, his name is even the first in the README (before the PSF is mentioned). Does he now have a position in PSF? Because that's just inviting problems given his past behaviour.
Is it possible that this move to the PSF is good then? Is Reitz involved in the project at all now?
As a side anecdote, from my own experience with bipolar friends and family that kind of private manipulation + large-scale deception seems sadly familiar. I'm not sure if it's a feature of bipolar disorder or if it's a sad coincidence in our experiences.
Judging by the commit history and the README.md, with his name in fancy cursive on top of the PSF logo, this seems to be the Kenneth Reitz Show featuring PSF at best.
I’ve heard extremely similar kinds of toxic things about the Anaconda / numpy world too.
Ranging from bizarre religion issues in the workplace to top-down bullying. Not the same e.g. no similar rumors about misused grants or donations, but a lot of creepy comments about management behavior in and around numfocus / anaconda / etc.
>He was deluged with donations from both individuals and large companies like Microsoft, Google, Slack, etc., and the fundraiser total quickly reached ~$30k.
Off topic, but the total looks disgustingly low, if companies like Microsoft, Google, and Slack have donated. Shame on them, they could splurge some more for the FOSS they use...
>On March 15 2018, he contacted me to talk about the fundraiser. He told me he was uncertain what to do with this amount of money – he said his original goal was just to raise $5k to buy a computer. Privately, I was skeptical that the $5k computer had anything to do with Requests. Requests is a small pure-Python library; if you want to work on it, then any cheap laptop is more than sufficient. $5k is the price of a beefy server or top-end gaming rig. But I figured that even if he spent $5k of the money on some unrelated computer, we could call that compensation for his past work, and it would still leave ~$25k to fulfill the promises he'd made in the fundraiser. And this was clearly a great opportunity to build some amazing new stuff. So I didn't say anything about the computer.
Until here, and if it's his project/fundraiser, it's his call. He could have spent it all on blow, and as long as he delivers the end result he raised funds for, it would be totally fine.
What he actually did in the end however (not work at all for the project and expect the volunteer to do it for free while he kept all the money) is a no go...
I'm well aware a suboptimal repository commit history hygiene doesn't necessarily correlate with the actual code quality, but yeah this really doesn't look nice nor convenient to work with. I wonder e.g. what the reason is behind pushing a hundred tiny updates to the README in one day, to master?
Why not make all the edits in one pass? It just looks horrendous. I wonder though, is there a git history fixer out there somewhere that rewrites history to merge commits with the same message into one?
`git rebase -i` and then change `pick` to `squash` for the ones you want squashed, but if you’ve pushed all the commits to master you’re now going to have to force-push master, which is... sub-optimal.
I am not. Manually issuing rebranch is too slow for any git histories over a few hundred. You'd then also have to find which commits you want to merge, merge them and so on and on. Rebranch basically works if you just want to fix one mistake in history you know you have.
... what? `rebranch` isn't a command in git? I think you mean rebase, and sure, if you were rebasing the entire history it would be slow and awful. But don't do that. Rebase at like `HEAD~10` (or whatever) to only clean up the last 10 commits. There's no performance issues or even management issues. Maybe go read the rebasing section (https://git-scm.com/book/en/v2/Git-Branching-Rebasing) of the git manual...
I... like, the first comment in the thread I asked if there's a tool that could go over the entire git history of a repo and fix such issues up, rebase isn't a solution in that case because it does get slow and it requires manual work which is slow, I don't understand how people are losing the context so quickly here.
Your comment didn't say "the entire git history of a repo", and in the context of this thread, people made the reasonable assumption your were talking about a few sequential commits, as discussed regarding the edits to README on the Requests repo.
I disagree about it not being slow, it depends on hardware. In addition to that I did not ask about how to fix a commit history manually, I asked for a tool that would go over an entire commit history and automatically fix the issues for me.
Read the thread next time. I started by asking if there's a fixer and then someone suggests a single command that absolutely doesn't solve the problem and would take enormous time to use on some projects, even more so if your PC isn't the best of the best.
OK, I see your original comment, no need to be rude. If you're working on a computer that struggles with 'making a commit' and 'editing a text file', I feel like you're working in an environment that's going to be very frustrating when writing code.
Are you thinking about rebasing through an IDE? IDEs are uniformly terrible at git.
I just don't like downvotes because people take comments out of context.
I am not thinking about rebasing trough an IDE. Try rebasing in Chromium's repository, it's simply not fast. The thing I asked for is something that would auto-fix the entire commit histories in cases such as the Requests repository, the suggested use of rebase is too tedious and slow. Has something still remained unclear?
> Try rebasing in Chromium's repository, it's simply not fast
The intent for a tool which could do this quickly is unclear. Rebasing millions of commits will be slow, also rebasing published history will also generate a lot of extra paperwork.
Writing a utility to sort a rebase todo by message and change the later commits with the same message to be fixups is trivial.
Late to the party, but it would be trivial to use `git rebase -i` and a decent editor to fix the Requests commit history. I just gave it a go locally and got good results with less than a minute's editing.
“You” are a developer, why the heck are “you” working in a textarea rather than a proper editor? Updating a readme is not the sort of thing that you have to do urgently from a coffee shop while on holiday in South Asia...
Apparently the README is very important for this project. How else could I learn that it's the most downloaded python package and that I can certainly trust it?
> Tbf, a lot of python projects have .rst README files, and getting a local preview can be more of a pain than looking at the GH preview in the browser.
rst may be less popular than md but there's no shortage of local preview options, including plugins/extensions for popular editors.
Git gives you the tools to do that effectively. Namely cheap branching and rebasing. That means you can commit to your heart's content on your own branch, then squash it all down to something useful for master. A hundred tiny commits on a shared branch is just being a bad citizen.
It makes sense to say backup early, backup often. Commits in a version control system that's meant to keep track of development history aren't really meant to be used as a backup system. Just as a backup system isn't really meant to keep track of development history.
That feels harsh, but honestly, I think it doesn't make sense for him to have control of master. Let him make branches and do PRs like everyone else. Obviously we know that when he's in the right frame of mind he's a good coder, but when he's not he can easily break master for a hugely popular piece of infrastructure. It doesn't play to his strengths to make him the controller of master.
Looks like what? Seems like just a recent bunch of many fine grained edits to the README...
This however, from TFA, is troubling:
I think a lot of people don't realize how little Reitz actually has to do with Requests development. For many years now, actual maintenance has been done almost exclusively by other volunteers. If you look at the maintainers list on PyPI, you'll see he doesn't have PyPI rights to his own project, because he kept breaking stuff, so the real maintainers insisted on revoking his access. If you clone the Requests git repo, you can run git log requests/ to see a list of every time someone changed the library's source code, either directly or by merging someone else's pull request. The last time Reitz did either was in May 2017, when he made some whitespace cleanups.
At least as far as commits go, his main contributions since then appear to consist of merging some small doc fixes, and monetizing the project by adding donation links, ads, intrusive sponsored links, etc. All of this money goes directly into his pocket, not the project's maintainers.
This move is not new. It has been there for a while. Kenneth is the only one committing right now and none of the people who can make new releases are maintaining it. At the moment master is accidentally broken on 2.x, has a bunch of questionable merges in it and CI is failing.
I have been told that the PSF is aware of these issues.
61 comments
[ 2.7 ms ] story [ 146 ms ] thread[0] https://github.com/psf/requests/commits/master
Your link has a typo: https://github.com/numpy/numpy/commits/master
https://vorpus.org/blog/why-im-not-collaborating-with-kennet...
"But none of the money was available to fulfill those commitments; instead, he was going to wait for me to implement the new features for him, and then he needed the entire $28k to pay for writing documentation for my features."
Instead I see he is still on the project, his name is even the first in the README (before the PSF is mentioned). Does he now have a position in PSF? Because that's just inviting problems given his past behaviour.
Is it possible that this move to the PSF is good then? Is Reitz involved in the project at all now?
As a side anecdote, from my own experience with bipolar friends and family that kind of private manipulation + large-scale deception seems sadly familiar. I'm not sure if it's a feature of bipolar disorder or if it's a sad coincidence in our experiences.
Judging by the commit history and the README.md, with his name in fancy cursive on top of the PSF logo, this seems to be the Kenneth Reitz Show featuring PSF at best.
Ranging from bizarre religion issues in the workplace to top-down bullying. Not the same e.g. no similar rumors about misused grants or donations, but a lot of creepy comments about management behavior in and around numfocus / anaconda / etc.
Off topic, but the total looks disgustingly low, if companies like Microsoft, Google, and Slack have donated. Shame on them, they could splurge some more for the FOSS they use...
>On March 15 2018, he contacted me to talk about the fundraiser. He told me he was uncertain what to do with this amount of money – he said his original goal was just to raise $5k to buy a computer. Privately, I was skeptical that the $5k computer had anything to do with Requests. Requests is a small pure-Python library; if you want to work on it, then any cheap laptop is more than sufficient. $5k is the price of a beefy server or top-end gaming rig. But I figured that even if he spent $5k of the money on some unrelated computer, we could call that compensation for his past work, and it would still leave ~$25k to fulfill the promises he'd made in the fundraiser. And this was clearly a great opportunity to build some amazing new stuff. So I didn't say anything about the computer.
Until here, and if it's his project/fundraiser, it's his call. He could have spent it all on blow, and as long as he delivers the end result he raised funds for, it would be totally fine.
What he actually did in the end however (not work at all for the project and expect the volunteer to do it for free while he kept all the money) is a no go...
I'm well aware a suboptimal repository commit history hygiene doesn't necessarily correlate with the actual code quality, but yeah this really doesn't look nice nor convenient to work with. I wonder e.g. what the reason is behind pushing a hundred tiny updates to the README in one day, to master?
Rebase isn't at all slow. I know this because I do it often to squash my own commits or move things around between branches.
> Nah, rebase is too slow on large histories and it might not be your own commit which complicates things.
I don't see any questions being asked. Rebase on the commits we're discussing (readme tweaks) are trivial: fixup fixup fixup
Read the thread next time. I started by asking if there's a fixer and then someone suggests a single command that absolutely doesn't solve the problem and would take enormous time to use on some projects, even more so if your PC isn't the best of the best.
Are you thinking about rebasing through an IDE? IDEs are uniformly terrible at git.
I am not thinking about rebasing trough an IDE. Try rebasing in Chromium's repository, it's simply not fast. The thing I asked for is something that would auto-fix the entire commit histories in cases such as the Requests repository, the suggested use of rebase is too tedious and slow. Has something still remained unclear?
The intent for a tool which could do this quickly is unclear. Rebasing millions of commits will be slow, also rebasing published history will also generate a lot of extra paperwork.
Writing a utility to sort a rebase todo by message and change the later commits with the same message to be fixups is trivial.
That doesn’t apply in this case, though, where the README is markdown
rst may be less popular than md but there's no shortage of local preview options, including plugins/extensions for popular editors.
> You may certianly put your trust in this code.
This however, from TFA, is troubling:
I think a lot of people don't realize how little Reitz actually has to do with Requests development. For many years now, actual maintenance has been done almost exclusively by other volunteers. If you look at the maintainers list on PyPI, you'll see he doesn't have PyPI rights to his own project, because he kept breaking stuff, so the real maintainers insisted on revoking his access. If you clone the Requests git repo, you can run git log requests/ to see a list of every time someone changed the library's source code, either directly or by merging someone else's pull request. The last time Reitz did either was in May 2017, when he made some whitespace cleanups.
At least as far as commits go, his main contributions since then appear to consist of merging some small doc fixes, and monetizing the project by adding donation links, ads, intrusive sponsored links, etc. All of this money goes directly into his pocket, not the project's maintainers.
I have been told that the PSF is aware of these issues.