[core-workflow] GitHub migration update

[Maciej Szulik]

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?


>
> 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/f95f171c/attachment-0001.html>