<br><br><div class="gmail_quote">On Sun Nov 30 2014 at 12:00:20 PM Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Nov 30, 2014, at 11:44 AM, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:</div><br><div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Sun Nov 30 2014 at 10:55:26 AM Ian Cordasco <<a href="mailto:graffatcolmingov@gmail.com" target="_blank">graffatcolmingov@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Sun, Nov 30, 2014 at 7:01 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>> wrote:<br>> On Sun, 30 Nov 2014 16:23:08 +1100<br>> Chris Angelico <<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>> wrote:<br>>><br>>> Yes, GitHub is proprietary. But all of your actual code is stored in<br>>> git, which is free, and it's easy to push that to a new host somewhere<br>>> else, or create your own host. This proposal is for repositories that<br>>> don't need much in the way of issue trackers etc, so shifting away<br>>> from GitHub shouldn't demand anything beyond moving the repos<br>>> themselves.<br>><br>> I hope we're not proposing to move the issue trackers to github,<br>> otherwise I'm -1 on this PEP.<br>><br>> Regards<br>><br>> Antoine.<br><br>So I usually choose not to weigh in on discussions like these but<br>there seems to be a lot of misdirection in some of these arguments.<br><br>To start, I'm generally neutral about this proposal or Nick's proposal<br>that spurred this one. I've found the most frustrating part of<br>contributing to anything involving CPython to be the lack of reviewer<br>time. I have had very small (2-line) patches take months (close to a<br>year in reality) to get through in spite of periodically pinging the<br>appropriate people. Moving to git/GitHub will not alleviate this at<br>all.<br><br>To be clear, the main reasoning behind Nick's was being able to submit<br>changes without ever having to have a local copy of the repository in<br>question on your machine. Having a complete web workflow for editing<br>and contributing makes the barrier to entry far lower than switching<br>VCS or anything else. BitBucket (apparently, although I've never used<br>this) and GitHub both have this capability and *both* are<br>free-as-in-beer systems.<br><br>No one as I understand it is proposing that we use the per-distro<br>proprietary interface to these websites.<br><br>All data can be removed from GitHub using it's API and can generally<br>be converted to another platform. The same goes for BitBucket although<br>it's arguably easier to retrieve issue data from BitBucket than<br>GitHub. That said, *the issue tracker is not covered by these<br>proposals* so this is a moot point. Drop it already.<br><br>If we're seriously considering moving to git as a DVCS, we should<br>consider the real free-as-in-freedom alternatives that come very close<br>to GitHub and can be improved by us (even though they're not written<br>in Python). One of those is GitLab. We can self-host a GitLab instance<br>easily or we can rely on<span> </span><a href="http://gitlab.com/" target="_blank">gitlab.com</a>. GitLab aims to provide a very<br>similar user experience to GitHub and it's slowly approaching feature<br>parity and experience parity. GitLab is also what a lot of people<br>chose to switch to after the incident Steven mentioned, which I don't<br>think is something we should dismiss or ignore.<br><br>We should refocus the discussion with the following in mind:<br><br>- Migrating "data" from GitHub is easy. There are free-as-in-freedom<br>tools to do it and the only cost is the time it would take to monitor<br>the process<br><br>- GitHub has a toxic company culture that we should be aware of before<br>moving to it. They have a couple blog posts about attempting to change<br>it but employees became eerily silent after the incident and have<br>remained so from what I've personally seen.<br><br>- GitHub may be popular but there are popular FOSS solutions that<br>exist that we can also self-host at something like<span> </span><a href="http://forge.python.org/" target="_blank">forge.python.org</a><br><br>-<span> </span><a href="http://bugs.python.org/" target="_blank">bugs.python.org</a><span> </span>is not covered by any of these proposals<br><br>- The main benefit this proposal (and the proposal to move to<br>BitBucket) are seeking to achieve is an online editing experience<br>allowing for *anyone with a browser and an account* to contribute.<br>This to me is the only reason I would be +1 for either of these<br>proposals (if we can reach consensus).<br></blockquote><div><br></div><div>But that's not just it. As you pointed out, Ian, getting patch submissions committed faster would be a huge improvement over what we have today. GitHub/Bitbucket/whatever could help with this by giving core devs basic CI to know that I patch is sound to some extent as well as push button commits of patches.</div><div><br></div><div>For me personally, if I knew a simple patch integrated cleanly and passed on at least one buildbot -- when it wasn't a platform-specific fix -- then I could easily push a "Commit" button and be done with it (although this assumes single branch committing; doing this across branches makes all of this difficult unless we finally resolve our Misc/NEWS conflict issues so that in some instances it can be automated). Instead I have to wait until I have a clone I can push from, download a patch, apply it, run the unit tests myself, do the commit, and then repeat a subset of that to whatever branches make sense. It's a lot of work for which some things could be automated.</div></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div><div>Well there’s two sides to the contribution process.</div><div><br></div><div>There’s making things better/easier for people who *aren’t* committers and</div><div>there is making things better/easier for people who *are* committers. Tacking</div><div>extra things on to what we already have to improve the life of committers is</div><div>easier in many ways. As committers they’ve likely already taken the time to</div><div>learn the bespoke workflow that the Python project uses and have already gotten</div><div>through that particular hurdle. Looking to standardize around popular tools is</div><div>mostly about making it easier for *new* people and making it so that if they</div><div>learn this set of tools they can go an immediately apply that to most of the</div><div>other Python projects out there, or that if they are already contributing to</div><div>those other Python projects they are probably aware of this particular</div><div>toolchain and workflow and can apply that knowledge directly to the Python</div><div>project.</div><div><br></div><div>Moving to some of these tools happens to come with it features like really nice</div><div>CI integration and a nice "Merge" button that also make it a lot nicer for the</div><div>committer side of things.</div></div></div></blockquote><div><br></div><div>All very true, but if we can't improve both sides then we are simply going to end up with even more patches that we take a while to get around to. I want to end up with a solution that advances the situation for *both* committers and non-committers and I feel like that is being lost in the discussion somewhat. As the person who pushed for a migration to DVCS for non-committers I totally support improving the workflow for non-committers, but not at the cost of ignoring the latter half of the contribution workflow of committers which is a chronic problem.</div><div><br></div><div>As the PEP points out, the devguide, devinabox, and the PEPs have such a shallow development process that hosting them on Bitbucket wouldn't be a big thing. But if we don't view this as a long-term step towards moving cpython development somehow we are bifurcating our code contributors between git and hg which will be annoying. Now it could be argued that it doesn't matter for the peps and devguide since they are purely text and can be done easily through a web UI and a simple CI in Travis can be set up to make sure that the docs compile cleanly. But moving devinabox where there is going to be a code checkout in order to execute code for testing, etc. will be an issue.</div><div><br></div><div>So I guess my view is +0 for doc-only repos on GitHub as long as we make it clear we are doing it with the expectation that people will do everything through the web UI and never have to know git. But I can't advocate moving code over without moving ALL repos over to git -- hosting location doesn't matter to me -- to prevent having to know both DVCSs in order to do coding work related to Python; the cpython repo shouldn't become this vaunted repo that is special and so it's in hg long-term but everything else is on git.</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>I think it's also hard to get a representation of the people for whom the</div><div>bespoke workflow and less popular tooling are a problem for in a discussion</div><div>on python-dev. My guess is most of those people would not have signed up for</div><div>python-dev since, unless they were willing to take the time to learn that,</div><div>so there is an amount of selection bias at play here as well.</div></div></div></blockquote></div>