
CPython migration to GitHub scheduled for today - jaimebuelta
https://mail.python.org/pipermail/python-dev/2017-February/147341.html
======
gkya
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
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.

~~~
PerryCox
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
It doesn't solve the problem. I still can't see the PRs and comments stored in
github.

------
jaimebuelta
Background info:

[https://snarky.ca/the-history-behind-the-decision-to-move-
py...](https://snarky.ca/the-history-behind-the-decision-to-move-python-to-
github/)

~~~
tehwalrus
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
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
Brett Cannon's blog post ([https://snarky.ca/the-history-behind-the-decision-
to-move-py...](https://snarky.ca/the-history-behind-the-decision-to-move-
python-to-github/)) 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
> 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
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/)

------
luhn
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
Yes, they do switch to git today.

------
sandstrom
I wish Ruby would do this. And Mozilla/Firefox.

I think it would yield a lot of community contributions and developer
engagement.

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

~~~
samwillis
Just the code and pull requests. Not the issue tracker.

~~~
gkya
How come? The pull requests are handled as issues in Github, AFAIK.

~~~
aargh_aargh
They can be used independently.

------
jwilk
Migration PEP:

[https://www.python.org/dev/peps/pep-0512/](https://www.python.org/dev/peps/pep-0512/)

~~~
hobarrera
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
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
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.

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

------
Animats
83 forks already.

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

