I used the phrase 'too big to fork' in another thread.
-
@david_chisnall we have two very different views of reality, it appears.
@lritter So you maintain a fork of LibreOffice with custom features? Or Chromium? Or even something smaller like LLVM? Or any other million-line or larger project?
Have you, in fact, ever tried to do the thing that you’re saying is easy independent of scale? When someone does a refactoring upstream and removes a function that your local change was calling and changes a data structure that it relies on, version control makes it easy for you to keep the update? When this happens once a week, it’s easy for you to keep up with security updates and keep your custom feature working?
-
@lritter So you maintain a fork of LibreOffice with custom features? Or Chromium? Or even something smaller like LLVM? Or any other million-line or larger project?
Have you, in fact, ever tried to do the thing that you’re saying is easy independent of scale? When someone does a refactoring upstream and removes a function that your local change was calling and changes a data structure that it relies on, version control makes it easy for you to keep the update? When this happens once a week, it’s easy for you to keep up with security updates and keep your custom feature working?
@david_chisnall woah hey now, i didn't say it was easy. but you made it sound like it is impossible.
-
@david_chisnall woah hey now, i didn't say it was easy. but you made it sound like it is impossible.
@lritter You literally said that the tooling makes the size of the project irrelevant:
with source control, diffing, patching, merging, the size of the project does not matter.
And this is obviously incorrect for anyone who has maintained a fork of a large project for any length of time.
-
@lritter So you maintain a fork of LibreOffice with custom features? Or Chromium? Or even something smaller like LLVM? Or any other million-line or larger project?
Have you, in fact, ever tried to do the thing that you’re saying is easy independent of scale? When someone does a refactoring upstream and removes a function that your local change was calling and changes a data structure that it relies on, version control makes it easy for you to keep the update? When this happens once a week, it’s easy for you to keep up with security updates and keep your custom feature working?
i have no clue what the background of this discussion is but it popped into my notifications right before i went to bed and i personally agree with the take of tiny small easy to focus modules being true open source and big projects an anti pattern.
i wonder why somebody woupd say size doesnt matter. isnt it obvious that smaller is better?
...i mean - who knows, maybe we get stable reliable deterministic LLMs who lagically make size not matter, but for now
️ -
@lritter You literally said that the tooling makes the size of the project irrelevant:
with source control, diffing, patching, merging, the size of the project does not matter.
And this is obviously incorrect for anyone who has maintained a fork of a large project for any length of time.
@david_chisnall ok. maybe i was too optimistic in my wording.
what you just wrote about seems to weigh more heavily though: frequent breaking changes. and they can also occur in small projects.
-
@david_chisnall ok. maybe i was too optimistic in my wording.
what you just wrote about seems to weigh more heavily though: frequent breaking changes. and they can also occur in small projects.
@david_chisnall and when you depend on a bunch of small projects and they all break abi all the time, does it then make much of a difference if the dysfunctionality is monolithic or modular?
-
@david_chisnall and when you depend on a bunch of small projects and they all break abi all the time, does it then make much of a difference if the dysfunctionality is monolithic or modular?
If small projects break their APIs (or ABIs) all the time, that affects all of their users. If a large project breaks their internal APIs, that only affects downstream forks. That makes the cost-benefit calculations for them very different.
-
If small projects break their APIs (or ABIs) all the time, that affects all of their users. If a large project breaks their internal APIs, that only affects downstream forks. That makes the cost-benefit calculations for them very different.
@david_chisnall i would say this too depends on style and internal culture. but yes. there's a good reason why i always stuck to LLVMs/libclangs rather stable C ABI rather than messing around with their volatile class system. it takes them forever though to expose all the parts.
-
@david_chisnall i would say this too depends on style and internal culture. but yes. there's a good reason why i always stuck to LLVMs/libclangs rather stable C ABI rather than messing around with their volatile class system. it takes them forever though to expose all the parts.
@david_chisnall we can also debate how much of that is due to C++ leaking implementation details almost by design.
-
@david_chisnall we can also debate how much of that is due to C++ leaking implementation details almost by design.
C++ here doesn’t make a difference for forks. You can build stable public interfaces in C++ but it’s harder. But when you’re maintaining a fork, it’s the internal structure that matters. No amount of information hiding helps when you’re on the other side of that boundary. The Linux kernel is a good case study here: they strive for 100% ABI compatibility for things in userspace but routinely make changes that break out-of-tree kernel modules and cause huge merge headaches for downstream forks.
-
C++ here doesn’t make a difference for forks. You can build stable public interfaces in C++ but it’s harder. But when you’re maintaining a fork, it’s the internal structure that matters. No amount of information hiding helps when you’re on the other side of that boundary. The Linux kernel is a good case study here: they strive for 100% ABI compatibility for things in userspace but routinely make changes that break out-of-tree kernel modules and cause huge merge headaches for downstream forks.
@david_chisnall good points. what is your opinion on how they could fix it?
-
@david_chisnall good points. what is your opinion on how they could fix it?
I’ve written a lot on this subject, most recently this post, which is probably a good starting point.
-
@david_chisnall i'm familiar with conway's law. there is nothing to object to in this post except that it's too abstract to answer my question.
-
R relay@relay.mycrowd.ca shared this topic
