[core-workflow] We will be moving to GitHub

[Brett Cannon]

I was purposefully trying to avoid having this discussion start until
Monday, but since Ezio sort has a deadline for issue-related stuff we can
start on that side now (I still have an email planned on Monday to outline
the initial steps to moving things over and the very first hurdle to work
through).

On Fri, 1 Jan 2016 at 17:57 Ezio Melotti <ezio.melotti at gmail.com> wrote:

> Hi,
>
> On Fri, Jan 1, 2016 at 9:21 PM, Brett Cannon <brett at python.org> wrote:
> > I don't think this will be a shock to anyone who has followed the
> discussion
> > on this list. The decision is essentially based on:
> >
> > No major distinguishing features between GitHub or GitLab
> > Familiarity amongst core devs -- and external contributors -- with GitHub
> > Guido prefers GitHub
> >
> > Neither platform had some mind-blowing feature(s) that really made them
> > stand out from each other such that it would greatly simplify our lives
> if
> > we chose one platform over another. I obviously was really hoping there
> was
> > going to be something I missed, but nothing ever came up (and no, being
> open
> > source is not enough of a feature; as I said when I started this process,
> > being open source would help break ties or minor lead of one tool but
> not be
> > a deciding factor).
> >
> > But what Github does have over GitLab is familiarity. While there were
> > people who publicly said they would prefer not to go with GitHub but
> would
> > begrudgingly use it if we chose to go that route, I had multiple core
> devs
> > email me privately saying they hoped I would choose GitHub. I think most
> of
> > that stemmed from having used GitHub for other open source projects
> and/or
> > work, making even dormant core devs say they would be able to become
> active
> > again if we switched to GitHub thanks to eliminating the barrier of
> having
> > to keep up with our custom workflow for code reviews and using hg for
> > commits. And while I said it wasn't a goal to make things easier for
> > external contributors, I also can't ignore the fact that the vast
> majority
> > of people out there who might want to help out are already familiar with
> > GitHub.
> >
> > And at least for me, the fact Guido prefers GitHub means something. While
> > Guido himself would say I shouldn't really worry about his preferences
> since
> > he is only an occasional contributor at this point, I believe that it's
> > important that our BDFL actually like contributing to his own programming
> > language rather than potentially alienating him because he finds the
> process
> > burdensome.
> >
> > So that's why I have chosen GitHub over GitLab. Please realize that this
> is
> > choosing GitHub to provide repository hosting and code review; we are not
> > moving our issue tracker, nor are we moving our wiki. And the long-term
> plan
> > is to set up a bot that will handle our commit workflow which will help
> > isolate us from any repository hosting platform we are on and making
> moving
> > easier in the future (and short-term people will use the command-line and
> > that's totally platform-agnostic).
> >
> > Thanks to everyone who contributed to this decision, especially Donald,
> > Barry, and Nick for making the proposals we had to work from.
> >
> > We can start the discussion of how we want to handle the transition next
> > week, but I'm going to try and step away from this whole workflow topic
> > until Monday so I can spend the last couple of days of my vacation not
> > thinking about this stuff. :)
> >
>
> This will likely require a new PEP, that should cover:
>   1) the new workflow (including how to handle reviews -- see below);
>   2) the steps required for the migration and a timeline;
>   3) a list of things that will break and/or that will need to be
> added/replaced before/during/after the migration;
>   4) the fate of hg.python.org;
>

Yes to all of that.


>
> Some of these things might already be covered by existing PEPs, but I
> don't see them in PEP 507[0] and 481[1] (and I'm getting a bit lost
> among all the competing PEPs and multiple threads across at least a
> couple different MLs :).
>

It will be either be a new PEP or the GitHub PEP will simply be rewritten.


>
> Above you said that GitHub will be used for reviews but we will keep
> using our bug tracker.
>

Yes, we are not moving to GitHub's issue tracker.


> This leads to the following questions:
>   * Do GitHub reviews only work for pull requests?
>

What do you mean by this? Do you mean by patch upload?


>   * Are we still going to support uploading diffs/patches to the
> tracker (short term and long term)?
>

Well, "support" as in "allow". We won't be keeping Rietveld around (part of
this move is so we can get off of Rietveld).


>   * If so, how/where are we going to review those diffs/patches?
>

I don't know. Is it possible to have the bot create a PR for an uploaded
patch?


>   * Will patches be automatically converted to pull requests, or pull
> requests converted to patches and attached to b.p.o issues?
>

I don't think we need to upload a patch file if we already have a PR, but
we should either have a PR -> issue or issue -> PR mapping somehow. This
can either be via bot command or specifying a PR # in the issue tracker. I
also have no issue if people want to make PRs generate patches for the
issue as well for backup purposes, but that might get a bit noisy for those
following both an issue and a PR.


>   * Are there plans to migrate existing Rietveld reviews to GitHub and
> shut Rietveld down for good?
>

Yes, there are plans to shut Rietveld down. I suspect we will leave it up
until GitHub is running in an equivalent fashion to our current workflow,
then we will have a deadline to work through any outstanding reviews and
then close it up (and if we want to be thorough, set Rietveld so that it
won't work on new issues and only pre-existing ones that already have a
patch).


>   * If not, will Rietveld stay around and be read-only?  Or will it
> still be used for patches uploaded to b.p.o?
>

We are trying to cut down on the infrastructure we maintain, so I don't
want Rietveld sticking around indefinitely.


>   * What else is needed to integrate GitHub and b.p.o?
>

Basically a way to map an issue to a PR (or vice-versa). Probably the
simplest solution is to allow pasting in a GitHub PR URL or the PR # to
make the association. The other option is for the bot to accept a command
to make the association. No reason we can't have both, though. But either
way we should have a way to connect PRs to issues.

If a bot can create PRs from a patch, then that would be nice for folks who
don't want to use GitHub, but I don't consider that a priority. I'm happy
to try to be accommodating to people who don't want to use GitHub for
whatever reason, there is a limit to how much energy we should put into
supporting that scenario past uploading a patch.


>
> About points 3 of the initial list, these are some examples of things
> that will need to be added/updated/replaced:
>   * the hgroundup hook[2] that post messages to b.p.o when a commit
> includes an issue number needs to be replaced;
>   * the hgirker hook[3] used for deadparrot on #python-dev needs to be
> replaced (probably there is already an irker-git hook that can be
> used/adapted);
>   * the hgbuildbot[4] hook that triggers the buildbots on commit needs
> to be replaced;
>   * other hg hooks[5] might need to be rewritten/replaced;
>   * the script[6] that generates bug tracker links to hg.p.o needs to
> be updated (for both cs ids and paths);
>   * the hg code that converts issue links in commit messages to b.p.o
> links needs to be replaced;
>   * other places where issue numbers appears on GitHub should generate
> links to b.p.o;
>   * the hg-cpydev hg extension [7] should be ported to git (optional);
>   * the buildbots need to be updated if they are going to pull the
> source from github and use git;
>   * the bug tracker will need to be updated to interact with github;
>   * the devguide needs to be updated (both to cover the new workflow
> and update links/commands);
>

Yes to all of these (I think; depends if we change how something operates
in terms of associations).


>
> FWIW next weekend (9-10 January) we are organizing a sprint in
> Helsinki, and I'm planning to work on the bug tracker, so I might be
> able to start addressing some of these points.
>

I think deciding how to associate issues with PRs would be a great thing to
work through. Otherwise we need to decide if we want to go with an issue
tracker solution to the NEWS file or if we want a individual file solution
(which happens to be bot-friendly). Those two things are probably the most
critical starting points.

-Brett


>
> Best Regards,
> Ezio Melotti
>
> P.S. enjoy your last few days of vacation while you can ;)
>
> [0]: https://www.python.org/dev/peps/pep-0507/
> [1]: https://www.python.org/dev/peps/pep-0481/
> [2]: https://hg.python.org/hooks/file/tip/hgroundup.py
> [3]: https://hg.python.org/hooks/file/tip/hgirker.py
> [4]: https://hg.python.org/hooks/file/tip/hgbuildbot.py
> [5]: https://hg.python.org/hooks/file/tip
> [6]:
> https://hg.python.org/tracker/python-dev/file/tip/extensions/local_replace.py
> [7]: https://bitbucket.org/introom/hg-cpydev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160102/0f7f006b/attachment.html>