In this talk, I will present you the reason of the move to GitHub and the status after this move. Please read it and you can be ready for your future contribution, because we are ready for your Pull Requests.
Make sure it still applies cleanly Fix the conflicts or ask a new patch to the contributor Run test suite manually (10-15 min) Commit the change manually Write the commit message Commit in the maintenance branches first and then merged in the default branch Run the test suite manually again Commit the merge Push the changes 18 / 89
conflicts Try to find the original author No description about the behaviour of the patch Problem, sometimes, there is no reference about the revision Difficult to rebase diff --git a/Misc/python.man b/Misc/python.man --- a/Misc/python.man +++ b/Misc/python.man 19 / 89
(between 1h & 1d... if we are lucky) Frequent bugs on Windows the developers are on Linux or OSX or just too lazy If green, port to several branches can introduce new bugs in the other branches risk of conflicts tests executed by Buildbot 20 / 89
(between 1h & 1d... if we are lucky) Frequent bugs on Windows the developers are on Linux or OSX or just too lazy If green, port to several branches can introduce new bugs in the other branches risk of conflicts tests executed by Buildbot CI: Only on the stable branches (2.7, 3.4+) 21 / 89
for Mercurial PyPI 62% for Git 22% for Mercurial 13% for the rest Why Git? Git is 3 times more popupar as Mercurial for the top 100 projects on PyPI. 30 / 89
to contribute to a project Avoid a custom infrastructure for the volunteers Example, Rietveld was a custom fork and not maintained a lot of developers are familiar with GitHub GitHub Pull Requests has a major advantage over the older "submit a patch to a bug tracker" model. GitHub Pull Requests are easier to review have nice syntax hightligted diffs can be commented 32 / 89
Donald Stufft Ernest W Durbin Ezio Melotti Maciej Szulik Mariatta Wijaya Nick Coghlan Oleg Broytman Senthil Kumaran and me Seriously, you can congratulate them Orchestrated by Brett Cannon and these volunteers https://mail.python.org/pipermail/python-committers/2017-February/004220.html 46 / 89
performance tests Compile the documentation Execute make patchcheck Check if files have been generated Execute for master and the stable branches (2.7, 3.6) Execute on the branches from the contributors Automation 48 / 89
a Misc/NEWS.d/next entry with bedevere/news play with the labels awaiting review, awaiting merge, awaiting core review Bedevere! https://github.com/python/bedevere 50 / 89
Agreement aka CLA The knights who say ni! https://github.com/python/the-knights-who-say-ni CLA: https://www.python.org/psf/contrib/contrib-form/ 51 / 89
all the descriptions for each change. really difficult to merge when you receive a PR or a patch. => it's a real pain for the core-developers and the contributors discussion is here: https://github.com/python/core-workflow/issues/6 61 / 89
tool which manage the Misc/NEWS.d entries an individual file per news entry! > cat Misc/NEWS.d/next/IDLE/2018-03-05-01-29-05.bpo-32984.NGjgT4.rst And it's a ReStructured Text file format ;-) https://github.com/python/core-workflow 63 / 89
Dev Wait a review of a Core Dev Download the patch Fix the conflicts Run the tests manually Run the code coverage manually Commit manually Write the commit message Merge into the branches Run the test suite manually Commit the merge Push the changes etc... process is long & manual & error prone 65 / 89
Dev Wait a review of a Core Dev Download the patch Fix the conflicts Run the tests manually Run the code coverage manually Commit manually Write the commit message Merge into the branches Run the test suite manually Commit the merge Push the changes etc... process is long & manual & error prone After Contributor Open an issue Clone Create a Pull Request Core Dev Review from contributors or core-dev Wait the feedback of the BOTS + Automation Wait the signal Mark the PR as needs backport to X.Y process is short & automatic 66 / 89