pull down to refresh
0 sats \ 6 replies \ @leaf 2h \ parent \ on: Undeprecate datacarrier PR rationale - @schmidty bitcoin
I think the community will always want a repo with a lot of eyes on it, to manage PRs and ensure changes are well reviewed.
If you had loads of code forks, it would be tough to know what has and hasn't been thoroughly reviewed. That won't cut it on a project that requires absolute reliability.
That's the problem now, Core just gets arbitrary changes through because there's the presumption of lots of eyes on it. People just download blindly with zero discernment because the repo is trusted.
If it were more splintered, or even just relocated, it would force people to know why they're downloading what they're downloading.
It doesn't mean another repo wouldn't result in exactly the same people doing the same exact things with the same number of eyes, but the shakeup would make "upgrades" explicit.
The rate of change in Core is obscene when compared to enterprise software and SCADA systems that extremely important processes are built upon. Bitcoin is akin to those types of systems as the backbone for trillions in value, but it's changed more like a fledgling javascript framework because of this disconnected relationship between stakeholders and the NGO's ability to use it as a laboratory because of a legacy they themselves didn't build.
This will blow up eventually, the case for archiving it is that when it does blow up the impact is isolated.
reply
People just download blindly with zero discernment because the repo is trusted.
They trust that others are looking at the code, and you get that with one main repo.
It's unrealistic to expect most people to start doing code review and verifying the code for themselves.
but it's changed more like a fledgling javascript framework
As I understand it, PRs are often in review for months or even years, if thet get merged at all. That's hardly like the javascript community.
Regardless, if there were multiple code forks, I'd expect that to reduce code security/reliability, not increase it. The eyeballs would be split between repos and there would be more chance of a bug or questionable change getting through.
reply
That's what I just said, people don't look at what they're downloading, they're trusting a false legacy. That's bad.
People that don't want to discern what they're downloading would then be less likely to download changes they don't need. That's good.
Core has multiple major versions per year, that's worse than many js frameworks.
The prescription isn't multiple forks, that just may be an outcome, the actual prescription is to prevent a politburo from impersonating Bitcoin.
reply
People that don't want to discern what they're downloading would then be less likely to download changes they don't need. That's good.
I'd say a loss in trust in bitcoin due to issues will be a bigger factor, even if those issues were isolated.
Core has multiple major versions per year, that's worse than many js frameworks.
That's not a metric I'd judge a project's coding practices by. I think something like the number of bugs and their severity would be better.
the actual prescription is to prevent a politburo from impersonating Bitcoin
I doubt that would happen. They might fool the gullible, but few else, imo. Certainly not big miners or businesses who would have a lot to lose if bitcoin failed.
reply
