
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 29, 2014, at 8:12 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" class="">ncoghlan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class=""><br class="">

On 30 Nov 2014 09:28, "Donald Stufft" <<a href="mailto:donald@stufft.io" class="">donald@stufft.io</a>> wrote:<br class="">

><br class="">

> As promised in the "Move selected documentation repos to PSF BitBucket<br class="">

> account?" thread I've written up a PEP for moving selected repositories from<br class="">

> <a href="http://hg.python.org/" class="">hg.python.org</a> to Github.<br class="">

><br class="">

> You can see this PEP online at: <a href="https://www.python.org/dev/peps/pep-0481/" class="">https://www.python.org/dev/peps/pep-0481/</a><br class="">

><br class="">

> I've also reproduced the PEP below for inline discussion.</p><p dir="ltr" class="">Given that <a href="http://hg.python.org/" class="">hg.python.org</a> isn't going anywhere, you could also use hg-git to maintain read-only mirrors at the existing URLs and minimise any breakage (as well as ensuring a full historical copy remains available on PSF infrastructure). Then the only change needed would be to set up appropriate GitHub web hooks to replace anything previously based on a commit hook rather than periodic polling.</p><div class=""><br class=""></div></div></blockquote><div><br class=""></div><div><div>Ah yes, I meant to include that and just forgot to do it when I went to test</div><div>hg-git to see how well it worked and whether I got different commit hashes on</div><div>different machines. I also thought about adding a <a href="http://git.python.org" class="">git.python.org</a> which just</div><div>acted as a read-only mirror of what was on Github, but I don’t know if that’s</div><div>actually generally useful or not.</div></div><br class=""><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">The PEP should also cover providing clear instructions for setting up git-remote-hg with the remaining Mercurial repos (most notably CPython), as well as documenting a supported workflow for generating patches based on the existing CPython GitHub mirror.</p><div class=""><br class=""></div></div></blockquote><div><br class=""></div><div><div>I can add this. I’ve never actually tried using git-remote-hg with CPython</div><div>itself because I’ve made it segfault on other Mercurial repositories and I</div><div>never figured out why so I just generally fight my way through using Mercurial</div><div>on projects that themselves use Mercurial. I will absolutely test to see if</div><div>git-remote-hg works with CPython and I can document using that to contribute to</div><div>CPython. I’m not sure it needs to be part of the PEP or not? Feels like</div><div>something that would be better inside the devguide itself but I’m not opposed</div><div>to putting it both locations.</div></div><br class=""><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">Beyond that, GitHub is indeed the most expedient option. My two main reasons for objecting to taking the expedient path are:</p></div></blockquote><div><br class=""></div><div>It's not entirely about expedience. I think a lot of the reason why we should</div><div>look towards outsourcing some of these items is that volunteer time is not</div><div>a fungible resource. Volunteers are generally only willing to work on things</div><div>which they personally care about. This is entirely unlike a business where you</div><div>have employees who will generally work on whatever you tell them to because</div><div>that's what you're paying them for. To this end I personally don't really have</div><div>an interest in trying to create a better code hosting platform than Github when</div><div>Github is doing an amazing job in my opinion and they satisify my needs fine.</div><div>Given the *current* state of tooling it appears that there are not a lot of</div><div>people who both care about making that piece of software exist and are capable</div><div>of competing with Github in terms of quality.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">1. I strongly believe that the long term sustainability of the overall open source community requires the availability and use of open source infrastructure. While I admire the ingenuity of the "free-as-in-beer" model for proprietary software companies fending off open source competition, I still know a proprietary platform play when I see one (and so do venture capitalists looking to extract monopoly rents from the industry in the future). (So yes, I regret relenting on this principle in previously suggesting the interim use of another proprietary hosted service)</p><div class=""><br class=""></div></div></blockquote><div><br class=""></div><div>I somewhat agree. However I’m less concerned specifically about where projects</div><div>are hosted exactly and more about the *ability* to move to a completely OSS</div><div>infrastructure. In particular if at somepoint we need to move off of Github we</div><div>can totally do that, it’s not particularly difficult. Currently you lose the</div><div>higher quality polish of Github if you do that however if at some point in the</div><div>future Github either turns evil or an OSS software offers a truly compelling</div><div>alternative to Github then there is really nothing stopping a migration to</div><div>another platform. As I said in the PEP I view this as a “let’s cross that</div><div>bridge if/when we get to it”. The main thing we should look at is things that</div><div>would be difficult to migrate away from. For code hosting in particular most of</div><div>the truly valuable data is stored within the DVCS so migrating the bulk of the</div><div>data is as simple as pushing the repository to a new location. The other data</div><div>is within the issues, for these repositories I suggest moving the issues to</div><div>Github entirely because I don’t suspect they’ll get many if any issues</div><div>themselves so the amount of data stored in issues will be low.</div><div><br class=""></div><div>However I also think that long term sustainability of any particular project</div><div>depends on attracting and retaining contributors. To this end going to where</div><div>the people are already and paving inroads that reduce the barriers to</div><div>contributing is an important thing to do as well. This proposal is aimed</div><div>squarely at reducing barriers to contribution while also giving a nod to the</div><div>first concern by selecting a platform that has done a lot to enable OSS and</div><div>doing it in a way that the ability to leave that platform is maintained so that</div><div>in some future we can migrate away if need be.</div><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">2. I also feel that this proposal is far too cavalier in not even discussing the possibility of helping out the Mercurial team to resolve their documentation and usability issues rather than just yelling at them "your tool isn't popular enough for us, and we find certain aspects of it too hard to use, so we're switching to something else rather than working with you to address our concerns". We consider the Mercurial team a significant enough part of the Python ecosystem that Matt was one of the folks specifically invited to the 2014 language summit to discuss their concerns around the Python 3 transition. Yet we'd prefer to switch to something else entirely rather than organising a sprint with them at PyCon to help ensure that our existing Mercurial based infrastructure is approachable for git & GitHub users? (And yes, I consider some of the core Mercurial devs to be friends, so this isn't an entirely abstract concern for me)</p></div></blockquote><div><br class=""></div><div>I was on the fence about including the bit about branches in the PEP itself and</div><div>I ended up doing it only because multiple people brought it up when I asked</div><div>them for a review. I also tried not to include the fact that I haven’t</div><div>personally figured out how to actually use Mercurial effectively in the PEP</div><div>itself because honestly I don’t think that is really the core idea behind</div><div>moving to git and Github. I think if you look at any semi objective measurement</div><div>between git and Mercurial’s effective popularity git is going to be a clear</div><div>winner, and if you do the same thing for Github compared to any other code</div><div>hosting service or software then Github wins that by any even larger margin.</div><div><br class=""></div><div>The reason the PEP primarily focuses on the popularity of the the tool is</div><div>because as you mentioned, issues like poor documentation, bad support for a</div><div>particular platform, a particular workflow not being very good can be solved by</div><div>working with the tool authors to solve that particular problem. I wouldn’t</div><div>consider those issues in a vacuum to be a good reason to migrate away from that</div><div>tool. However there’s very little that CPython can do to get more people using</div><div>Mercurial, and presumably the authors of Mercurial are already doing what they</div><div>can to get people to use them. However by choosing, and continuing to choose, a</div><div>tool that an order of magnitude less people use, we’re choosing to effectively</div><div>make it harder to contribute. We’re increasing the likelhood that a contributor</div><div>is going to have to learn our particular DVCS even if they already know one and</div><div>we’re increasing the likelhood that we’re burdening users to learn a technology</div><div>that isn’t going to transfer to most other projects that they might want to</div><div>contribute to, even within the Python ecosystem itself.</div><div><br class=""></div><div>Even the suggestion of a way to make it approachable for git and Github users</div><div>still acts as a barrier to contribution. Now it’s true that when you have to</div><div>select against competing tools the tool you choose is going to be a barrier to</div><div>*someone*. For example if we do choose to go with git, then that tool will be a</div><div>barrier to people who already know Mercurial but don’t already know git.</div><div>However by selecting the most popular tool you ensure that the particular</div><div>barrier is a barrier to as few as people as possible. </div><div><br class=""></div><div>To be clear, I don’t consider the technical differences between Mercurial and</div><div>git to be very large hurdles to overcome, it’s primarily about the mindshare</div><div>and the fact that Mercurial doesn’t really enable us to do much that git</div><div>doesn’t also allow us to do (other than support friends, which isn’t an</div><div>unreasonable desire either) while keeping us from tapping into the collective</div><div>power of the number of git users. To put it another way, Linux vs the BSDs, I</div><div>actually prefer FreeBSD over Linux, but I almost never use it because Linux is</div><div>vastly more popular and by selecting it I’m more likely to be able to transfer</div><div>that knowledge to different scenarios and find help when I have a problem.</div></div><div><br class=""><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">Given my proposal to use BitBucket as a near term solution for enabling pull request based workflows, it's clear I consider the second argument the more significant of the two.</p><p dir="ltr" class=""> However, if others consider some short term convenience that may or may not attract additional contributors more important than supporting the broader Python and open source communities (an argument I'm more used to hearing in the ruthlessly commercial environment of Red Hat, rather than in upstream contexts that tend to be less worried about "efficiency at any cost"), I'm not going to expend energy trying to prevent a change I disagree with on principle, but will instead work to eliminate (or significantly reduce) the current expedience argument in GitHub's favour.</p><div class=""><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">As a result, I'm -0 on the PEP, rather than -1 (and will try to stay out of further discussions).</p><p dir="ltr" class="">Given this proposal, I'm planning to refocus PEPs 474 & 462 specifically on resolving the CPython core workflow issues, since that will require infrastructure customisation regardless, and heavy customisation of GitHub based infrastructure requires opting in to the use of the GitHub specific APIs that create platform lockin. (Note that the argument in PEP 481 about saving overall infrastructure work is likely spurious - the vast majority of that work will be in addressing the complex CPython workflow requirements, and moving some support repos to GitHub does little to alleviate that</p></div></blockquote><div>That was specifically about saving infrastructure work to supporting Kallithea</div><div>(or whatever solution). I don’t suspect that CPython was planning on using</div><div>Kallithea (maybe I’m wrong?) so <a href="http://forge.python.org" class="">forge.python.org</a> was primarily aimed towards</div><div>the non-CPython repositories.</div><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">If folks decide they want to migrate the ancillary repos back from GitHub after that other infrastructure work is done, so be it, but if they don't, that's OK too. We're already running heterogeneous infrastructure across multiple services (especially if you also take PyPA into account), so having additional support repos externally hosted isn't that big a deal from a purely practical perspective.</p></div></blockquote></div><br class=""><div class="">

<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">---</div><div class="">Donald Stufft</div><div class="">PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA</div></div></div>

</div>

<br class=""></body></html>