[Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

[Donald Stufft]

> On Nov 30, 2014, at 11:28 AM, Brett Cannon <brett at python.org> wrote:
> 
> 
> 
> On Sat Nov 29 2014 at 7:16:34 PM Alex Gaynor <alex.gaynor at gmail.com <mailto:alex.gaynor at gmail.com>> wrote:
> Donald Stufft <donald <at> stufft.io <http://stufft.io/>> writes:
> 
> >
> > [words words words]
> >
> 
> I strongly support this PEP. I'd like to share two pieces of information. Both
> of these are personal anecdotes:
> 
> For the past several years, I've been a contributor on two major projects using
> mercurial, CPython and PyPy. PyPy has a strong culture of in-repo branching,
> basically all contributors regularly make branches in the main repo for their
> work, and we're very free in giving people commit rights, so almost everyone
> working on PyPy in any way has this level of access. This workflow works ok. I
> don't love it as much as git, but it's fine, it's not an impediment to my work.
> 
> By contrast, CPython does not have this type of workflow, there are almost no
> in-tree branches besides the 2.7, 3.4, etc. ones. Despite being a regular hg
> user for years, I have no idea how to create a local-only branch, or a branch
> which is pushed to a remote (to use the git term). I also don't generally
> commit my own work to CPython, even though I have push privledges,
> because I
> prefer to *always* get code review on my work. As a result, I use a git mirror
> of CPython to do all my work, and generate patches from that.
> 
> The conclusion I draw from this is that hg's workflow is probably fine if
> you're a committer on the project, or don't ever need to maintain multiple
> patches concurrently (and thus can just leave everything uncommitted in the
> repo). However, the hg workflow seems extremely defficient at non-committer
> contributors.
> 
> One way to come close to that using hg is to have your own clone that you never push to hg.python.org/cpython <http://hg.python.org/cpython> (e.g. cloning the Bitbucket clone of cpython or hosting on hg.python.org <http://hg.python.org/> a personal clone). You can then specify the repo and branch on the issue tracker to generate your patch: https://docs.python.org/devguide/triaging.html#mercurial-repository <https://docs.python.org/devguide/triaging.html#mercurial-repository> . After that it's just like any other patch workflow for core devs. It's not quite as nice as maybe using named branches where you can just do a final hg merge/commit to get your changes committed, but if you're not going to commit your branches then you might as well get the automatic patch generation perk in the issue tracker rather than using git (unless there is some other git feature you use that you can't get in hg).

This doesn’t really work in a Pull Request workflow though I think is the point.
Uploading patches is it’s own kind of terrible but yes if you’re just uploading
patches you can probably do that. I don’t make branches in Mercurial because
i’m afraid I’m going to push a permanent branch to hg.python.org <http://hg.python.org/> and screw
something up.

>  
> 
> The seconds experience I have is that of Django's migration to git and github.
> For a long time we were on SVN, and we were very resistant to moving to
> DVCS in
> general, and github in particular. Multiple times I said that I didn't see how
> exporting a patch and uploading it to trac was more difficult than sending a
> pull request. That was very wrong on my part.
> 
> My primary observation is not about new contributors though, it's actually
> about the behavior of core developers. Before we were on github, it was fairly
> rare for core developers to ask for reviews for anything besides *gigantic*
> patches, we'd mostly just commit stuff to trunk. Since the switch to github,
> I've seen that core developers are *far* more likely to ask for reviews of
> their work before merging.
>  
> Why specifically? Did you have a web UI for reviewing patches previously? Do you have CI set up for patches now and didn't before? What features did you specifically gain from the switch to GitHub that you didn't have before? IOW was it the "magic" of GitHub or some technical solution that you got as part of the GitHub package and thus could theoretically be replicated on python.org <http://python.org/>?

In most of the cases there was some form of a web UI for reviewing patches. I
don’t believe there was a CI setup for patches previously and most projects do
end up with some sort of CI on Github since Travis makes it particularly easy.
Honestly though, I feel like the main reason for it is just that Github’s
solution is easy to use, it works with the VCS which is great because that’s
what I’m using already, and it’s highly polished.

OSS has a long history of having rather poor UX, and poor UX tends to mean that
people would rather not use some particular thing unless they *have* to. That
is the way I look at Rietveld to be honest. I get frustrated trying to use it
so I'd rather just not use it where I feel I can get away with it. It's not
really enough to look at a feature matrix and then go "yup we something in
all the checkboxes" which it seems that OSS software likes to try and do when
comparing themselves to a well done, but non-OSS solution.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141130/7d71af24/attachment.html>