CPython migration to GitHub scheduled for today
mail.python.org
mail.python.org
And you really think people might not be able to attach a diff to an email? I just don't see this dystopian future. For what it's worth I use GitHub but have essentially no brand loyalty to it.
But then again, learning how to do it probably takes 5 minutes...
If the OP is that worried about github going down, just add a pushurl in .git/config to another host and that solves the problem.
To me that sort of makes things worse. I have nothing against using GitHub as such, but I also think it's important that projects like this should lead by example. If you centralize things that are inherently decentralized it's hard to make a case that decentralization is important.
> many people (including myself) prefer the command line where possible, which is essentially universal and not hard to pick up at all.
As someone who, at least thinks they, understands how DVCS works I find the git command line quite unintuitive. It's a mix between more low level commands and added shortcuts. The solution becomes "just run these three commands you know and use Github".
> In a worst case scenario the entire project could be preserved with history and exported.
That's not really realistic, unless something really drastic happens. People often use Github for more than git itself, it becomes an integral part of the workflow. If it's was easy to switch people would run something else in parallel (which some projects do).
All in all I think the pragmatic solution is to have your own system and then interface Github as one channel. If you can't set up your own system that is competitive as a completment to Github, well then you are effectively dependent on Github.
So while I agree that an open and distributed system that does what github is currently doing would be better, I don't think that github's popularity and eventual demise is as terrible as you claim.
Trying to figure out which of these scenarios (or a different one!) is going to happen sure looks like optimizing prematurely to me, in particular so long as there does exist some fashion of a backup repository.
Planning in the 20 or 50 years range is counter-productive.
Heck, whole countries might not exist by that time (the same way ex-USSR and Eastern European countries split into different ones).
Now you have me thinking about how to plan that long! You would need an architecture easy to port and good documentation...
Or become so important that old platforms are maintained for your sake!
The guy in charge of making the decision weighed the fact that it's closed source, and it still won.
> But to me, the development process is more important than worrying whether a cloud-based service publishes its source code... This is especially not a worry as GitHub is not a walled garden; its extensive SDK allows for downloading any and all data that goes into the platform.
In summary, his reasons were: github has become a social network of open source devs; gitlab has no killer features github doesn't; and Guido prefers github
https://snarky.ca/the-history-behind-the-decision-to-move-py...
How many minutes does it take to learn those skills?
If your criteria is only depending on things that are not gonna fail someday, you'll be severely limited in your options.
Any decentralized solution would require money and people to host it (per project), would not provide a uniform interface to developers and users of code, and would not be as mature as GitHub is (at least initially).
Besides, git is decentralized -- so people will have copies of the repo anyway, which they can backup fully anywhere they like. As for issues, etc, they could get them from GitHub for future-proofing and store them somewhere -- if GitHub fails them for some reason, they could then make some importers and load the same issues, notes etc on another host.
>Is it really that hard to set up Trac or sth.?
Given that GitHub hosts 10,000s of projects, it would mean several collective man-years lost for no reason. And in the end you'll have Trac to face (which is something to avoid in itself).
I'm not quite happy with it, but it's better than nothing.
Unless home servers were used, in which case you're already paying for the bandwidth for your home internet connection.
All you'd really want to add on top of that is a decentralised identity layer, for managing permissions across all repositories.
Serious question: What's so bad about Trac?
Granted, I wish that the issues were stored within a branch, so that they would be copied along with the repository.
https://snarky.ca/the-history-behind-the-decision-to-move-py...
(The link is a very detailed blog post about why this migration is happening, and what alternatives to GitHub were considered).
Afair it was because at the time decision was beeing made it wasn't open source, as it is now.
“The second lesson I learned was about the dedication of volunteers. When the decision was made to switch to JIRA, one of the key attractions of that platform was that Atlassian was going to be hosting our instance and providing direct support (they were very involved in their proposal). But when the community started to protest over the idea of a closed-source, Java application I publicly said if we could get enough volunteers to manage our own Roundup instance then I would relent to using Roundup. There was actually a decent number of people who stepped forward, so we switched (the FSF offered to help put the call out for volunteers but in the end I didn't take them up on the offer as my own personal call seemed to bring enough volunteers forward). But what ended up happening is nearly none of those volunteers stuck around. At this point we have Ezio Melotti and R. David Murray to thank -- both core developers -- for keeping our issue tracker up an running and Upfront Systems for hosting it. This experience taught me that the people you can really count on are those that put the effort into the proposals themselves and those with a proven track record. While people who come out of nowhere have good intentions, that doesn't guarantee they will actually follow through (which I honestly should have known based on my experience from the Python core sprints at PyCon where people used to regularly come to tackle a big problem, get part way to a solution, swear they will finish when they get home, and then never be heard from again).”
That's not a slight on anyone but just an acknowledgement that there's no shortcut for ops. Moving the core Python repo to GitHub outsources that to a fairly large company's primary business and is staffed accordingly. For a project without major corporate support not having to manage a complex service is a big selling point.
This was the best part of your post, which finally convinced me this was a good idea.
"... PEP 474 ... Nick proposed moving to Kallithea ... Nick Coghlan subsequently saying he would rather back GitLab over Kallithea (due to maturity issues of the projects) ..."
I think it would yield a lot of community contributions and developer engagement.
> People preferred having a single commit representing a single change instead of having a set of unrelated commits lead to a merge commit that represented a single change.
Commit 1: Add a user model Commit 2: Add migrations for user model Commit 3: Implement endpoints for users
Squashing them is pointless, and mixing them into a linear history really adds no value.
I do agree with squashing commits than cancel each other out inside a branch.