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 firstname.lastname@example.org wrote:
On Fri, Jan 1, 2016 at 9:21 PM, Brett Cannon email@example.com wrote:
I don't think this will be a shock to anyone who has followed the
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
we chose one platform over another. I obviously was really hoping there
going to be something I missed, but nothing ever came up (and no, being
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
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
begrudgingly use it if we chose to go that route, I had multiple core
email me privately saying they hoped I would choose GitHub. I think most
that stemmed from having used GitHub for other open source projects
work, making even dormant core devs say they would be able to become
again if we switched to GitHub thanks to eliminating the barrier of
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
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
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
So that's why I have chosen GitHub over GitLab. Please realize that this
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
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
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:
- the new workflow (including how to handle reviews -- see below);
- the steps required for the migration and a timeline;
- 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 and 481 (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 that post messages to b.p.o when a commit
includes an issue number needs to be replaced;
- the hgirker hook 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 hook that triggers the buildbots on commit needs
to be replaced;
- other hg hooks might need to be rewritten/replaced;
- the script 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  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.
Best Regards, Ezio Melotti
P.S. enjoy your last few days of vacation while you can ;)