It can be more productive than trying to resolve conflicts internally. But yeah someone has to actually do the work.
In this case the fork was created by someone who has never worked on Calibre before and they haven’t even cherry picked out the AI commits yet, only updated the readme.
Some are certainly long enough or quibble-over-terminology enough to make a Trot paper blush… though they are usually a fair bit better on the signal to noise ratio, unless a maintainer’s having an ideological rant they’re often only long because software is complicated.
Yeah, but it also makes “forking” into a more ambiguous term overall. A GitHub fork can be a clone with a working branch or an actual fork and it’s not immediately obvious until you look at the code.
That’s why I use the README test to see if a forked repo is an actual fork since almost no one will modify the README if their GitHub fork is actually a work branch.
Esoecially when it’s a massive and from what I hear messily coded thing like Calibre. I’ve been looking for alternatives for a long time but nothing has the massive variety of features that Calibre has for library and book management.
Booklore is looking promising. It’s more like Calibre Web than plain Calibre though in that its an app you host and access via browser rather than just having your local Calibre install. It’s got some bugs still when it comes to book ingestion, but it doesn’t rely on a Calibre database whatsoever and just uses and optionally embeds book metadata, so you can just point it at your book folder and go.
I love forks like this because they almost always last a long time.
yeah unless a core maintainer moves over too they’re nothingburgers sadly. Anyone can make a fork has its benefits but not always!
forks are the software equivalent of party splits except somehow even pettier.
It can be more productive than trying to resolve conflicts internally. But yeah someone has to actually do the work.
In this case the fork was created by someone who has never worked on Calibre before and they haven’t even cherry picked out the AI commits yet, only updated the readme.
See, this is how you know open source is communist, your favourite piece of software has the exact same sectarianism problems as your local Trots!
And the readmes, issue posts, and notes on merges are sort of like newspapers if you squint hard enough, too.
Some are certainly long enough or quibble-over-terminology enough to make a Trot paper blush… though they are usually a fair bit better on the signal to noise ratio, unless a maintainer’s having an ideological rant they’re often only long because software is complicated.
Not always, all PRs usually start as forks unless the person is part of the project and can do their work on a branch.
That’s just a Githubism
Yeah, but it also makes “forking” into a more ambiguous term overall. A GitHub fork can be a clone with a working branch or an actual fork and it’s not immediately obvious until you look at the code.
That’s why I use the README test to see if a forked repo is an actual fork since almost no one will modify the README if their GitHub fork is actually a work branch.
Esoecially when it’s a massive and from what I hear messily coded thing like Calibre. I’ve been looking for alternatives for a long time but nothing has the massive variety of features that Calibre has for library and book management.
Booklore is looking promising. It’s more like Calibre Web than plain Calibre though in that its an app you host and access via browser rather than just having your local Calibre install. It’s got some bugs still when it comes to book ingestion, but it doesn’t rely on a Calibre database whatsoever and just uses and optionally embeds book metadata, so you can just point it at your book folder and go.