https://twitter.com/akashtrikon/status/1154823428106403840
so now that Github is starting its shenanigans with developers accounts, do you all still see this as not an issue?
https://twitter.com/akashtrikon/status/1154823428106403840
so now that Github is starting its shenanigans with developers accounts, do you all still see this as not an issue?
I think we could make a rule that patches and reviews may also be submitted via a mailing list, as not to exclude contributors whose account was blocked?
I agree with the @MarcoFalke's proposal here. Maybe some bot could even automatically create pull request in GitHub when it detects patch in an e-mail?
As i posted on issue #13411, Github sanctions now in effect in Crimea. This is a very serious issue, they could censor out developers who are contributing here based on IP. Lets say I decide to visit banned country, they could block any future development even if I don't necessarily live there.
I think we could make a rule that patches and reviews may also be submitted via a mailing list, as not to exclude contributors whose account was blocked?
I would hope that the mailing list is selected such that no centralised entity controls it
I think this is the first real, concrete reason to consider moving away from github. i think it is ridiculous to let US trade policy affect an international project this way.
I personally really dislike mailing lists though. I posted about this on mastodon recently: https://x0f.org/@orionwl/102507189698980502
It could be an option of last resort though.
I would hope that the mailing list is selected such that no centralised entity controls it
I don't think that is realistic, the hub-and-spoke way mailing lists work there's no actual way of doing that.
(I changed the PR title to make more sense: this is not about Microsoft specifically, this could just as well have happened with Github as independent startup!)
I would hope that the mailing list is selected such that no centralised entity controls it
But I definitely agree that any replacement should ideally be federated, or make migration easier. Moving to another system with a single point of failure (like a non-self-hosted gitea or gitlab instance) might just be kicking the can down the road a bit until whatever country it's hosted in makes the same demands.
(edit: at least when it's self-hosted it can always be moved, though only by the person hosting it; unless there's some database export functionality on the API)
In my opinion we need to get away from GitHub. Supporting a platform which is banning people because of some politics is against the fundamentals of bitcoin. The proposal that MarcoFalke proposed is too oldish and a dirty solution in my opinion. Also this might be against the Debian Free Software Guidelines (Point 5) I agree with laanwj that we should move to a self hosted git server. Another idea would be to get under the hood of another open-source project like GNOME (who are hosting their own GitLab instance where also projects like GIMP are hosted) but I think hosting a server would be a better idea but then we have the question who is responsible for the server and who is paying it?
Also GitLab can import other stuffs from GitHub beside the repository like:
See more here
but then we have the question who is responsible for the server and who is paying it?
Right. Setting up and hosting a small Gitlab/Gitea instance is quite easy, however, one facilitating a large project like this would see a lot of traffic and visitors and probably get a lot of hack attempts, too. It will not be a small job to manage this.
There's also the issue of trust. Github has been, at least up to now, a reasonable neutral third party. The one running the server could be tempted to manipulate reviews / ACKs or discussion, for example. Github could also do this but we've always assumed they don't have the incentive, whereas someone close to the project might.
Another reason to use signed ACKs, I suppose.
The mentioned concerns of who should be responsible to host this with the chance of getting hacked is for sure a huge problem that is not easy to solve but if we could build a federation of mirrors and later have a way to sync them up (first read-only, then across all mirrors). For paying/providing such a mirror I would think that many companies and individuals would do that if it is easy enough.
Without thinking to deep about if it is feasible what about:
1st step: Having a one or many GitLab instances as a read-only mirror directly from GH would still be helpful?
2nd step: Build something like GitLabs enterprise edition called Geo but open source. To be able to have few servers sync from GH directly but many to sync from other GitLab mirrors.
3rd step: (no idea how) make that sync a 2-way-sync (across all mirrors) so that it does not matter on which GitLab host you enter a comment, review or pr, they all sync up in a few minutes. You would still have some troubles if one mirror gets hacked but maybe there is also a good risk/reward ratio to make this feasible. When working, ditch GH.
Make it easy like BTCPayServer (or maybe like Debian mirrors) to install and sync up and distribute the repo across many peers.
I would love to see Bitcoin move to a decentralized GitHub alternative like git-ssb
https://github.com/noffle/git-ssb-intro https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256
Git-ssb is definitely usable today. I admit that I don't know enough to say whether it could handle a project the size of Bitcoin, but I would say that it warrants some investigating.
I had the idea of doing something similar like the Linux Foundation . The idea is to found a non-profit organization which is responsible as a legal person for the git server, domain control of bitcoincore.org, organizing CoreDev meetings and all this stuff.
The "constitution" of this non-profit organization could cover democratic internal structures, the goal of this organization, the new member process and more. But then we would have the question left in which country the organization would be registered. I don't know the laws and regulations in other countries but in Germany we have something called "Eingetragener Verein". For example projects like KDE, Wikipedia Germany use this.
I think that the net effect of completely moving away from GitHub at this point would exclude more developers than it would include. That may change in the future or perhaps contributors want to get rid of GitHub now as a matter of principle.
I think a temporary band-aid would be having proxies for GitHub that both mirror the data and allow users to make comments and pull requests that will be relayed to GitHub with a bot. This would be a good amount of engineering work that would potentially benefit very few contributors, so I would actually argue "don't do anything until it gets worse".
If it does get worse, BitcoinACKs.com (which is open source https://github.com/pierrerochard/bitcoin-acks ) does already mirror a lot of the data and it could be put on Tor and extended to proxy actions to GitHub.
I think we could make a rule that patches and reviews may also be submitted via a mailing list, as not to exclude contributors whose account was blocked? @laanwj
I think this is the first real, concrete reason to consider moving away from github.
Just to make sure we get the facts correct here:
Individual open source contributors living in these countries will still be free to contribute as usual to public open source repos such as bitcoin/bitcoin, right?
Individual open source contributors living in these countries will still be free to contribute as usual to public open source repos such as bitcoin/bitcoin, right?
This particular sanction only talks about exportation, so it should be fine
https://www.treasury.gov/resource-center/sanctions/Programs/Documents/ukraine_gl_9.pdf
I think that the net effect of completely moving away from GitHub at this point would exclude more developers than it would include.
That was a valid argument when bitcoin was a small, unknown project. I'm sure people that want to contribute to it are now willing to make another user/password pair t.b.h., just as they'd do the same to contribute to the linux kernel, ubuntu, freedesktop projects, and some of the other large projects that have used their own project hosting forever. (it even happens that people create github accounts sometimes to contribute to us, we're bringing them customers, don't underestimate it at this point)
FWIW, I hate to break it to you, but GitLab is VC backed by In-Q-Tel which is CIA. They have their fingers in everybody, just check the list.
https://www.iqt.org/portfolio/ https://mattermark.com/q-tel-cias-vc-arm-busy-years/
@thehapax Sure that this even applies to self-hosted ones?
This has been discussed in the meeting and it seems that those GitHub users can still contribute to public repos (e.g this repo), but not to private ones.
http://www.erisian.com.au/bitcoin-core-dev/log-2019-08-01.html#l-585
So nothing requires action from our side. I think it still makes sense to keep #13411 (Moving to self-hosted issue and patch management) in mind, but there is no pressing need.