<br><br><div class="gmail_quote">On Sun Nov 23 2014 at 3:04:05 PM Georg Brandl <<a href="mailto:g.brandl@gmx.net">g.brandl@gmx.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/23/2014 05:55 PM, Brett Cannon wrote:<br>
<br>
> I guess my question is who and what is going to be disrupted if we go with<br>
> Guido's suggestion of switching to GitHub for code hosting? Contributors won't<br>
> be disrupted at all since most people are more familiar with GitHub vs.<br>
> Bitbucket (how many times have we all heard the fact someone has even learned<br>
> Mercurial just to contribute to Python?). Core developers might be based on some<br>
> learned workflow, but I'm willing to bet we all know git at this point (and for<br>
> those of us who still don't like it, myself included, there are GUI apps to<br>
> paper over it or hg-git for those that prefer a CLI). Our infrastructure will<br>
> need to be updated, but how much of it is that hg-specific short of the command<br>
> to checkout out the repo? Obviously Bitbucket is much more minor by simply<br>
> updating just a URL, but changing `hg clone` to `git clone` isn't crazy either.<br>
> Georg, Antoine, or Benjamin can point out if I'm wrong on this, maybe Donald or<br>
> someone in the infrastructure committee.<br>
<br>
Well, since "most people" already know git this part is probably not a big deal,<br>
although we'd have to consider alienating core developers who are not git-savvy.<br>
<br>
> Probably the biggest thing I can think of that would need updating is our commit<br>
> hooks. Once again Georg, Antoine, or Benjamin could say how difficult it would<br>
> be to update those hooks.<br>
<br>
There are two categories of hooks we use: hooks that run before a push is<br>
accepted, and hooks that run afterwards. The latter are not a concern, since<br>
anything that GH/BB doesn't support can be run as a web service on <a href="http://python.org" target="_blank">python.org</a><br>
infrastructure, which then gets POST requests from the hosting platforms. These<br>
are<br>
<br>
* tracker update<br>
* IRC notification<br>
* sending email to python-checkins<br>
* triggering buildbot<br>
<br>
The more problematic category are pre-push hooks. We use them for checking<br>
and rejecting commits with<br>
<br>
* disallowed branches<br>
* non-conformant whitespace<br>
* wrong EOL style<br>
* multiple heads per named branch<br>
<br>
As far as I know, neither GH nor BB support such hooks, since they are highly<br>
project-specific. However, they are only used in cpython and related<br>
repositories, so that doesn't concern migration of doc-only repos.<br>
<br>
Sure, you can let the CI run the checks, but that doesn't prohibit merging<br>
and is circumvented by direct pushes to the repository that don't go through<br>
the PR system. (And please don't make me as a coredev open a PR for every<br>
change.)<br></blockquote><div><br></div><div>I'm not even going to touch the idea of requiring code review for all patches in the middle of this discussion. =) </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> From my perspective, swapping out Mercurial for git achieves exactly nothing<br>
> in terms of alleviating the review bottleneck (since the core developers<br>
> that strongly prefer the git UI will already be using an adapter), and is in<br>
> fact likely to make it worse by putting the greatest burden in adapting to<br>
> the change on the folks that are already under the greatest time pressure.<br>
><br>
><br>
> That's not entirely true. If you are pushing a PR shift in our patch acceptance<br>
> workflow then Bitbucket vs. GitHub isn't fundamentally any different in terms of<br>
> benefit, and I would honestly argue that GitHub's PR experience is better. IOW<br>
> either platform is of equal benefit.<br>
<br>
In my opinion, scattering repos over github, bitbucket and <a href="http://hg.python.org" target="_blank">hg.python.org</a> is<br>
even less friendly to contributors than a centralized place. (We are already<br>
approaching this, with pydotorg and infrastructure repos on github.) So I'm<br>
going to add some thoughts here about migrating the main CPython to git+hub.<br></blockquote><div><br></div><div>I don't think we would ever split ourselves across three separate hosting services. At most I see two -- one for docs, one for CPython -- but I would honestly expect it to be only one long-term.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We have to consider how well our branch workflow works with the PR<br>
workflow. There's no gain in the ability to easily merge a PR to one branch<br>
via github when the subsequent merge of 3.x to default/master requires a local<br>
pull/push cycle, as well as the 2.x backport.<br>
<br>
As far as I know, you'd have to open a pull/merge request yourself and instantly<br>
merge it, except if there are conflicts between branches, in which case you<br>
are again forced to go local. I don't need to mention that this doesn't work<br>
well when someone makes a concurrent commit to the source branch in the<br>
meantime.<br>
<br>
And I don't think you'd want to force people to submit 3 pull requests for<br>
the individual branches.<br>
<br>
The next point is that there is no easy way to change the target branch of<br>
a pull request (on github or bitbucket). People will usually make patches<br>
against the master branch unless told differently explicitly, which means<br>
that the pull request will also be against the master branch. Which means,<br>
close the PR, ask submitter to resubmit against 3.x branch, or do it<br>
yourself.<br></blockquote><div><br></div><div>How do other projects tend to manage their bugfix vs. in-dev branches? Is it a lot of cherrypicking? Probably our long development cycles doesn't help with this as it makes cross-branch merging difficult thanks to divergence, else this could be automated somehow or simply not be an issue. Otherwise we would have to do a merge from branch to branch locally as we do now and make sure people committed in the branch we wanted them to.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> It's also worth keeping in mind that changing the underlying VCS means<br>
> changing *all* the automation scripts, rather than just updating the<br>
> configuration settings to reflect a new hosting URL.<br>
><br>
><br>
> What are the automation scripts there are that would require updating? I would<br>
> like to a list and to have the difficulty of moving them mentioned to know what<br>
> the impact would be.<br>
<br>
Compiling that list is likely the most difficult step of updating them.<br></blockquote><div><br></div><div>That's what I figured and why I didn't want them viewed as a blocker.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> So here is what I want to know to focus this discussion:<br>
<br>
[...]<br>
<br>
> Third, do our release managers care about hg vs. git strongly? They probably use<br>
> the DVCS the most directly and at a lower level by necessity compared to anyone<br>
> else.<br>
<br>
I wouldn't care about git or hg. What I *might* care about is the low-level<br>
access to the repository on <a href="http://hg.python.org" target="_blank">hg.python.org</a>, mainly because of the hooks.<br>
<br>
> Fourth, do any core developers feel strongly about not using GitHub? Now please<br>
> notice I said "GitHub" and not "git"; I think the proper way to frame this whole<br>
> discussion is we are deciding if we want to switch to Bitbucket or GitHub who<br>
> provide a low-level API for their version control storage service through hg or<br>
> git, respectively. I personally dislike git, but I really like GitHub and I<br>
> don't even notice git there since I use GitHub's OS X app; as I said, I view<br>
> this as choosing a platform and not the underlying DVCS as I have happily chosen<br>
> to access the GitHub hosting service through an app that is not git (it's like<br>
> accessing a web app through it's web page or its REST API).<br>
<br>
Github is a nice platform, but many of its features would not be relevant for<br>
the cpython repo (e.g. issue tracker or wiki). The usefulness of pull requests<br>
is dubious, see above.<br>
<br>
The "but it is much easier to contribute simple changes" argument is a bit<br>
simplified: for any nontrivial patch, the time spent on working out the code<br>
should outweight time spent with "hg diff" or "click on pull request". And<br>
while Travis CI is nice, running relevant tests locally is *much* quicker than<br>
waiting for a full test suite run on a virtualized testing machine.<br></blockquote><div><br></div><div>Sure, but it's definitely easier to just wait for the Travis green on the PR than have to apply a patch and run the tests myself manually.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As for typo fixes, the world does not end when some typos aren't fixed.<br>
Anyway, for the docs we have an explicit offer to send anything, patch or<br>
just suggestion, to <a href="mailto:docs@python.org" target="_blank">docs@python.org</a>, and people do make use of it. No<br>
github account even required.<br></blockquote><div><br></div><div>Which is great, but I'm willing to bet clicking "Edit" in GitHub is easier still than creating the patch and emailing it. I have contributed doc fixes to a bunch of projects because of that "Edit" button (which is why I think Nick is so anxious to get it). If I had to do any checkout then I wouldn't have done them. And even having to email a diff might be too much for some changes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> At least for me, until we get a clear understanding of what workflow changes we<br>
> are asking for both contributors and core developers and exactly what work would<br>
> be necessary to update our infrastructure for either Bitbucket or GitHub we<br>
> can't really have a reasonable discussion that isn't going to be full of guessing.<br>
<br>
As for svn->hg, a PEP and a champion would be necessary, this time with the<br>
possibility of being rejected.<br>
<br>
> And I'm still in support no matter what of breaking out the HOWTOs and the<br>
> tutorial into their own repos for easier updating (having to update the Python<br>
> porting HOWTO in three branches is a pain when it should be consistent across<br>
> Python releases).<br>
<br>
I see no problem with that, provided there's a cronjob that syncs the version<br>
in Doc/ to the external version reasonably often.<br></blockquote><div><br></div><div>Would that really be necessary? At least for the HOWTOs how often are they edited simultaneously as some code in CPython? The Clinic HOWTO is probably the only one that might get updated simultaneously. I'd also be curious to know how often the tutorial is updated simultaneously as well.</div></div>