8 ms·

CPython migration to GitHub scheduled for today

105 points by jaimebuelta 10y ago

jaimebuelta 10y ago
Background info: https://snarky.ca/the-history-behind-the-decision-to-move-python-to-github/ https://snarky.ca/the-history-behind-the-decision-to-move-py...
- tehwalrus 10y ago
  Thank you for posting. (The link is a very detailed blog post about why this migration is happening, and what alternatives to GitHub were considered).
marcinkuzminski 10y ago
It's a shame they didn't pick a solution like RhodeCode(which is written in Python) at that point. Afair it was because at the time decision was beeing made it wasn't open source, as it is now.
- acdha 10y ago
  Brett Cannon's blog post (https://snarky.ca/the-history-behind-the-decision-to-move-python-to-github/ https://snarky.ca/the-history-behind-the-decision-to-move-py...) has been linked a bit and covers the general areas like the social aspects but your remark about open-source hit what I think is a fairly important point in the section about volunteer time: “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.
  - mixmastamyk 10y ago
    > 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.
    - 1wd 10y ago
      It may also interest you that Kallithea, an open source fork of the GPLv3 release of RhodeCode and member project of the Software Freedom Conservancy, was in the running at some point. From the same blog post: "... 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) ..." https://kallithea-scm.org/ https://kallithea-scm.org/
aviraldg 10y ago
Are the migrating only the code, or the issue tracker as well?
- samwillis 10y ago
  Just the code and pull requests. Not the issue tracker.
  - gkya 10y ago
    How come? The pull requests are handled as issues in Github, AFAIK.
    - aargh_aargh 10y ago
      They can be used independently.
gkya 10y ago
I really dislike the trend of open-source software centralising around GitHub. It's slowly becoming a single point of failure in the ecosystem, and it's closed and corporate software. One day it's going to fail. And we'll be left with a plethora of people who don't know how to patch a file or attach a diff to an email. Sad. Is it really that hard to set up Trac or sth.?
- dsacco 10y ago
  But git itself is decentralized. Even if software projects are centralized around GitHub, many people (including myself) prefer the command line where possible, which is essentially universal and not hard to pick up at all. In a worst case scenario the entire project could be preserved with history and exported. 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.
  - the_duke 10y ago
    There are plenty of devs who don't know about patches and have never used `git format-patch` or `git apply`. But then again, learning how to do it probably takes 5 minutes...
  - PerryCox 10y ago
    Yeah that's exactly how I feel. I've used all three (gitlab, bitbucket, and github). 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.
    - hobarrera 10y ago
      It doesn't solve the problem. I still can't see the PRs and comments stored in github.
  - reloop 10y ago
    > But git itself is decentralized. 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.
luhn 10y ago
More notable to me, last I checked Python was still using Mercurial. Are they also switching to git today or did I miss that migration?
- jwilk 10y ago
  Yes, they do switch to git today.
jwilk 10y ago
Migration PEP: https://www.python.org/dev/peps/pep-0512/ https://www.python.org/dev/peps/pep-0512/
- hobarrera 10y ago
  The PEP mentions that they'll be using a linear git history (no merges), but doesn't explain any of the reasons or perceived advantages of doing so. I found this pretty curious because (1) PEPs tend to explain why a decision is made, much like an RFC would (2) it's the really odd choice to make.
  - progval 10y ago
    The important part is not for it to be linear, it's to have each PR squashed. Linearity is just a consequence: > 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.
    - hobarrera 10y ago
      That justifies squashing inside a PR, but not making it linear. Commits might be coherently separated, eg: 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.
Animats 10y ago
83 forks already.
- derimagia 10y ago
  There's a lot of people who fork who really shouldn't be who use it like the "star" function.
Daviey 10y ago
So much top level metadata now... .git / .github, .bzrignore, 4 mercurial files and travis.yml.
sandstrom 10y ago
I wish Ruby would do this. And Mozilla/Firefox. I think it would yield a lot of community contributions and developer engagement.

105 points by jaimebuelta 10y ago

Background info: https://snarky.ca/the-history-behind-the-decision-to-move-python-to-github/ https://snarky.ca/the-history-behind-the-decision-to-move-py...

tehwalrus 10y ago
Thank you for posting. (The link is a very detailed blog post about why this migration is happening, and what alternatives to GitHub were considered).

marcinkuzminski 10y ago

It's a shame they didn't pick a solution like RhodeCode(which is written in Python) at that point. Afair it was because at the time decision was beeing made it wasn't open source, as it is now.

acdha 10y ago
Brett Cannon's blog post (https://snarky.ca/the-history-behind-the-decision-to-move-python-to-github/ https://snarky.ca/the-history-behind-the-decision-to-move-py...) has been linked a bit and covers the general areas like the social aspects but your remark about open-source hit what I think is a fairly important point in the section about volunteer time: “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.
- mixmastamyk 10y ago
  > 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.
  - 1wd 10y ago
    It may also interest you that Kallithea, an open source fork of the GPLv3 release of RhodeCode and member project of the Software Freedom Conservancy, was in the running at some point. From the same blog post: "... 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) ..." https://kallithea-scm.org/ https://kallithea-scm.org/

aviraldg 10y ago

Are the migrating only the code, or the issue tracker as well?

samwillis 10y ago
Just the code and pull requests. Not the issue tracker.
- gkya 10y ago
  How come? The pull requests are handled as issues in Github, AFAIK.
  - aargh_aargh 10y ago
    They can be used independently.

gkya 10y ago

I really dislike the trend of open-source software centralising around GitHub. It's slowly becoming a single point of failure in the ecosystem, and it's closed and corporate software. One day it's going to fail. And we'll be left with a plethora of people who don't know how to patch a file or attach a diff to an email. Sad. Is it really that hard to set up Trac or sth.?

dsacco 10y ago
But git itself is decentralized. Even if software projects are centralized around GitHub, many people (including myself) prefer the command line where possible, which is essentially universal and not hard to pick up at all. In a worst case scenario the entire project could be preserved with history and exported. 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.
- the_duke 10y ago
  There are plenty of devs who don't know about patches and have never used `git format-patch` or `git apply`. But then again, learning how to do it probably takes 5 minutes...
- PerryCox 10y ago
  Yeah that's exactly how I feel. I've used all three (gitlab, bitbucket, and github). 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.
  - hobarrera 10y ago
    It doesn't solve the problem. I still can't see the PRs and comments stored in github.
- reloop 10y ago
  > But git itself is decentralized. 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.

luhn 10y ago

More notable to me, last I checked Python was still using Mercurial. Are they also switching to git today or did I miss that migration?

jwilk 10y ago
Yes, they do switch to git today.

jwilk 10y ago

Migration PEP: https://www.python.org/dev/peps/pep-0512/ https://www.python.org/dev/peps/pep-0512/

hobarrera 10y ago
The PEP mentions that they'll be using a linear git history (no merges), but doesn't explain any of the reasons or perceived advantages of doing so. I found this pretty curious because (1) PEPs tend to explain why a decision is made, much like an RFC would (2) it's the really odd choice to make.
- progval 10y ago
  The important part is not for it to be linear, it's to have each PR squashed. Linearity is just a consequence: > 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.
  - hobarrera 10y ago
    That justifies squashing inside a PR, but not making it linear. Commits might be coherently separated, eg: 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.

Animats 10y ago

83 forks already.

derimagia 10y ago
There's a lot of people who fork who really shouldn't be who use it like the "star" function.

Daviey 10y ago

So much top level metadata now... .git / .github, .bzrignore, 4 mercurial files and travis.yml.

sandstrom 10y ago

I wish Ruby would do this. And Mozilla/Firefox. I think it would yield a lot of community contributions and developer engagement.