this post was submitted on 03 Jun 2024
397 points (96.5% liked)
Technology
59589 readers
3300 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The Debian community already maintains a Chromium fork. How much does that cost?
The human time needed should grow with the number of patches that need to be applied to the upstream code base, because some will fail now and then. This is what I refer to as "fatness" of the fork. The more patches, the fatter. It should be possible to build, packege and publish a fork with zero patches without human intervention, after the initial automation work. Testing is done by the users as it always has been in Debian and its derivatives. You're referring to a few full-time developers and I simply don't see the need. Maybe I'm missing something obvious. ๐
I honestly can't and wouldn't judge: Time, Resources, implicit know-how etc. are unknown to me.
jupp
Forks are done due to different reasons. Therefore it depends why to fork. It could be possible that one feature diverges so much that applying patches isn't enough. Especially patches in a debian sense, neither .diff/.patch-patches.
For a brief period, until something rattles on the build system. Debian patches are often applied to remove binary blobs due to licensing - Imagine upstream chooses to include M$ Recall into the render engine. You would need to apply extraordinary amounts of work. Maybe even maintaining a complete separate implementation. This would also imply changes on the build systems, which needs to get aligned continiously between both upstreams, now.
With each version you have to very carefully review every commit if you want to maintain compatability with upstream, in order to merge patches into your fork.
When there are 50 devs working on upstream and you need to review every commit to assure requirement X, this alone is a hard path. If you need to also apply workarounds compatible with future versions of upstream, you need PROFESSIONALS. Luckily these are found in the FOSS community; But they are underpaid and worse: underappreciated.
// plus I could imagine that things like chrome may even not be coming with the full test suite. The test suite of a browser are surely so huge I can't even comprehend the effort put into it. And then bug tickets.. Upstream says: Not in my version. Now the fork has to address these themselves! :)
Add into that, I'm betting googie will actively try to make downstream forks difficult to maintain without accepting the components they want to force on everyone like manifest v3
Don't hate google too much..! They are an essential company to the west world; They contribute a lot to the community.
As long there is no business interest, the developers there are very competent and would defend their architectural choices I want to believe.
But yes, they - as a whole - have earned such a mistrust by now very much IMO.
I have no interest in giving them the benefit of any doubt, they not only haven't earned it but actively squandered and destroyed the trust they had earned in the past.
They'll actually have to do something to make themselves trustworthy again, and even if they do, there will always be the threat of them reverting to what they are now or worse looming over every good thing they do.
They not only became what they set out to oppose, they've become so much worse.