[core-workflow] GitHub migration update

[Brett Cannon]

On Thu, 6 Oct 2016 at 14:32 Maciej Szulik <soltysh at gmail.com> wrote:

> On Thu, Oct 6, 2016 at 9:41 PM, Brett Cannon <brett at snarky.ca> wrote:
>
> As always, the master TODO list is kept at
> https://www.python.org/dev/peps/pep-0512/#cpython-repo . To summarize:
>
>    - The bugs.python.org changes have patches but they need to land
>    (hopefully Maciej Szulik or R. David Murray can help with that)
>
> I'll sync with David and Ezio about it and will keep my hand on it. I
> don't have commit rights to
> roundup repos ;)
>
>
>    -
>    - Ned Deily and R. David said they could help with the IRC and emails
>    to python-checkins at the core dev sprint last month (unless I'm
>    remembering wrong :)
>    - Ned said PEP 101 will get updated by him
>    - sys._git is coded but awaiting a code review by Ned (and probably
>    deciding if it should be in Python 3.6 or just straight into 3.7)
>    - Updating hg.python.org/lookup is still needed/desired
>    - Need to check if the current mirror is actually good enough to just
>    keeping using to avoid breaking everyone's clone of the repository, or if
>    we truly do need to fully regenerate the repo
>    - Need to finish updating the devguide
>
>
> So a bunch of stuff is in-progress which is great! Probably the thing that
> I need the most help with ATM is updating the devguide. There's a `github`
> branch at https://github.com/python/devguide/tree/github where we're
> trying to eliminate or move mentions of Mercurial over to Git (see
> https://github.com/python/devguide/milestone/1 for the relevant issues).
> We also need to figure out exactly what git commands we want for doing
> squash commits from the command-line (we will have the Squash and Merge
> button on GitHub, but some people prefer a CLI and the commands that GitHub
> provides are not squash ones), and we also need instructions on how to
> cherrypick a change that went into master but needs to be backported to an
> older version(s) of Python (I will start separate threads for that
> discussion).
>
>
> I can create a doc describing the cherry-pick, should I post a PR against
> that branch?
>
> The general flow should be very simple, such as:
> 1. find the commit you want to cherry-pick
> 2. switch to branch you're cherry-picking to
> 3. git cherry-pick sha
> 4. fix eventual incompatibilities
>
> With more words, that should be ok, wdyt?
>

Yep, a PR updating
https://github.com/python/devguide/blob/github/committing.rst (rendered at
http://cpython-devguide.readthedocs.io/en/github/committing.html, issue at
https://github.com/python/devguide/issues/44) would be great! I don't think
there's anywhere else in the devguide that directly relates to commits that
must be applied to multiple versions of Python.

-Brett


>
>
>
> At the core sprints last month, Ned and I talked and we agreed that we
> wouldn't switch until after 3.6.0 came out so as to not risk botching the
> release because of the migration. That means the switchover won't happen
> any sooner than mid/late December, but luckily most of this stuff can still
> be done (and tested) prior to officially switching so this doesn't need to
> hold anything up.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161006/f9e213bf/attachment.html>