From brett at python.org  Sat Dec  3 18:30:09 2016
From: brett at python.org (Brett Cannon)
Date: Sat, 03 Dec 2016 23:30:09 +0000
Subject: [core-workflow] Choosing a code coverage reporter
In-Reply-To: <CAP1=2W6nHxSU9UU6y5oFBaBzZ6RvtSqqZBF+X1pMXV9QH_Tx3Q@mail.gmail.com>
References: <CAP1=2W6nHxSU9UU6y5oFBaBzZ6RvtSqqZBF+X1pMXV9QH_Tx3Q@mail.gmail.com>
Message-ID: <CAP1=2W4nmsKZzDHwigRAQZbYW=NpJ8GqeJd2Y1nsHUhd5nGD2g@mail.gmail.com>

Codecov was the clear winner among people who left a reaction on the issue
and it's also my personal choice, so the code coverage reporter has been
chosen! Thanks to everyone who helped out with it.

On Tue, 22 Nov 2016 at 12:08 Brett Cannon <brett at python.org> wrote:

> I have both Codecov and Coveralls up and running. If you have an
> opinion/preference, please vote at
> https://github.com/brettcannon/cpython-ci-test/issues/27 using the
> reactions on the appropriate comment (.e.g +1/-1 reaction for Codecov
> and/or Coveralls). Links to the code coverage results are in the issue. If
> people want to see how they interact with PRs, feel free to look at
> https://github.com/brettcannon/cpython-ci-test/pull/32 (once the CI run
> is finished).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161203/fe28e7f6/attachment.html>

From brett at snarky.ca  Sat Dec  3 19:40:49 2016
From: brett at snarky.ca (Brett Cannon)
Date: Sun, 04 Dec 2016 00:40:49 +0000
Subject: [core-workflow] GitHub migration update for 2016-12-03
Message-ID: <CAP1=2W6WPNpA1hptE5=tYAE9yTOUT8DrNQ+Xa8ocTspsXfGSpQ@mail.gmail.com>

   - Started the conversation with Zach Ware about updating the buildbots
   (doesn't sound too troublesome)
   - Maciej and Ezio got a GitHub PR field added to bugs.python.org
      - Next step is to review
      http://psf.upfronthosting.co.za/roundup/meta/issue589 so that PRs
      automatically populate the field on b.p.o
      - Once we make the connection from PR to issue then
      http://psf.upfronthosting.co.za/roundup/meta/issue590 can be reviewed
      so that commits leave a comment on b.p.o
   - I got the code for hg.python.org/hglookup
      - Asking if there's any reason I can't post it publicly
      - Need to figure out the best way to extract all commit IDs from a
      Mercurial repoistory
      - Need to update the code to use the commit IDs (both 12 and 40
      character lengths) for linking to hg commits
      - Need to update the code to accept 10 or longer hashes from git
      (default used to be 7, but git 2.11 now calculates the shortest,
      unamibiguous hash and CPython is big enough to need 10 characters)
   - Everything else either requires we have moved over to GitHub or isn't
   a blocker
   - Chose Codecov for our code coverage provider!

I think that's everything that's blocking migration. If people want to help
then please have a look at
http://cpython-devguide.readthedocs.io/en/github/ and
see if anything was missed for the migration and/or help Ezio and Maciej
with the b.p.o changes.

As soon as we migrate we will want to solve the Misc/NEWS problem as that
will be the biggest pain point/regression compared to the hg workflow. You
can read the PEP for the chosen workflow if people want to start thinking
about a solution.

After fixing Misc/NEWS the next pain point will be coming up with the best
way to handle cherry picking (initially we will use labels to keep track of
PRs that need backporting, but obviously automating the creation of the
cherry picks as PRs would be great and this will require solving the
Misc/NEWS problem).

>From there things will simply be beneficial, e.g. automating Misc/ACKS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161204/0bfcf49c/attachment.html>

From solipsis at pitrou.net  Mon Dec  5 07:14:04 2016
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 5 Dec 2016 13:14:04 +0100
Subject: [core-workflow] GitHub migration update for 2016-12-03
References: <CAP1=2W6WPNpA1hptE5=tYAE9yTOUT8DrNQ+Xa8ocTspsXfGSpQ@mail.gmail.com>
Message-ID: <20161205131404.77898ab2@fsol>

On Sun, 04 Dec 2016 00:40:49 +0000
Brett Cannon <brett at snarky.ca> wrote:
>    - I got the code for hg.python.org/hglookup
>       - Asking if there's any reason I can't post it publicly

None than I can think of.

>       - Need to figure out the best way to extract all commit IDs from a
>       Mercurial repoistory

Probably iterate over all entries in the revlog and inspect the "extra"
field as is done in hglookup?  That way you can build a static mapping
of SVN rev -> hg changeset ID, and save it e.g. to a file.

>       - Need to update the code to use the commit IDs (both 12 and 40
>       character lengths) for linking to hg commits
>       - Need to update the code to accept 10 or longer hashes from git
>       (default used to be 7, but git 2.11 now calculates the shortest,
>       unamibiguous hash and CPython is big enough to need 10 characters)

I'm not sure I understand those two points, but that probably doesn't
matter.

Regards

Antoine.



From brett at python.org  Mon Dec  5 18:45:52 2016
From: brett at python.org (Brett Cannon)
Date: Mon, 05 Dec 2016 23:45:52 +0000
Subject: [core-workflow] GitHub migration update for 2016-12-03
In-Reply-To: <20161205131404.77898ab2@fsol>
References: <CAP1=2W6WPNpA1hptE5=tYAE9yTOUT8DrNQ+Xa8ocTspsXfGSpQ@mail.gmail.com>
 <20161205131404.77898ab2@fsol>
Message-ID: <CAP1=2W6PoWYW7akW1T395tHutKCennyPiaKxOqaaUr_wn555EA@mail.gmail.com>

On Mon, 5 Dec 2016 at 04:14 Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Sun, 04 Dec 2016 00:40:49 +0000
> Brett Cannon <brett at snarky.ca> wrote:
> >    - I got the code for hg.python.org/hglookup
> >       - Asking if there's any reason I can't post it publicly
>
> None than I can think of.
>
> >       - Need to figure out the best way to extract all commit IDs from a
> >       Mercurial repository
>
> Probably iterate over all entries in the revlog and inspect the "extra"
> field as is done in hglookup?  That way you can build a static mapping
> of SVN rev -> hg changeset ID, and save it e.g. to a file.
>
> >       - Need to update the code to use the commit IDs (both 12 and 40
> >       character lengths) for linking to hg commits
> >       - Need to update the code to accept 10 or longer hashes from git
> >       (default used to be 7, but git 2.11 now calculates the shortest,
> >       unamibiguous hash and CPython is big enough to need 10 characters)
>
> I'm not sure I understand those two points, but that probably doesn't
> matter.
>

hg.python.org/lookup says any hexadecimal number that is 12 or 40 digits is
an hg commit ID, but git uses 10 or 40 digits for our repo for a commit
hash. The 10 digit and 12 digit lengths don't clash but the 40 digit one
does.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161205/fd8ff121/attachment.html>

From solipsis at pitrou.net  Mon Dec  5 18:51:30 2016
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 6 Dec 2016 00:51:30 +0100
Subject: [core-workflow] GitHub migration update for 2016-12-03
References: <CAP1=2W6WPNpA1hptE5=tYAE9yTOUT8DrNQ+Xa8ocTspsXfGSpQ@mail.gmail.com>
 <20161205131404.77898ab2@fsol>
 <CAP1=2W6PoWYW7akW1T395tHutKCennyPiaKxOqaaUr_wn555EA@mail.gmail.com>
Message-ID: <20161206005130.39d0eb02@fsol>

On Mon, 05 Dec 2016 23:45:52 +0000
Brett Cannon <brett at python.org> wrote:
> >  
> > >       - Need to update the code to use the commit IDs (both 12 and 40
> > >       character lengths) for linking to hg commits
> > >       - Need to update the code to accept 10 or longer hashes from git
> > >       (default used to be 7, but git 2.11 now calculates the shortest,
> > >       unamibiguous hash and CPython is big enough to need 10 characters)  
> >
> > I'm not sure I understand those two points, but that probably doesn't
> > matter.
> >  
> 
> hg.python.org/lookup says any hexadecimal number that is 12 or 40 digits is
> an hg commit ID, but git uses 10 or 40 digits for our repo for a commit
> hash. The 10 digit and 12 digit lengths don't clash but the 40 digit one
> does.

I see.  Thanks for the clarification.

Regards

Antoine.



From solipsis at pitrou.net  Wed Dec  7 15:39:40 2016
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 7 Dec 2016 21:39:40 +0100
Subject: [core-workflow] Fate of SVN externals
Message-ID: <20161207213940.42245cd5@fsol>


Hello,

Windows builds rely on hand-maintained copies (sometimes patched) of
external libraries.  Those copies are currently maintained in SVN
(yes, you read this correctly).  The URL is
http://svn.python.org/projects/external/

Not only does this mandate an additional dependency to run a Windows
build (I don't think we use SVN anywhere else), but it actually makes
them unpleasantly slower, because SVN is crappy at making checkouts.

Is it planned to move that repo to git?

Regards

Antoine.



From zachary.ware+pydev at gmail.com  Wed Dec  7 16:17:20 2016
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Wed, 7 Dec 2016 15:17:20 -0600
Subject: [core-workflow] Fate of SVN externals
In-Reply-To: <20161207213940.42245cd5@fsol>
References: <20161207213940.42245cd5@fsol>
Message-ID: <CAKJDb-O3ySC+Ks+S5bkmbc3K9_HYNAgtMDE7KcutCfn4NrrC2A@mail.gmail.com>

On Wed, Dec 7, 2016 at 2:39 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Hello,
>
> Windows builds rely on hand-maintained copies (sometimes patched) of
> external libraries.  Those copies are currently maintained in SVN
> (yes, you read this correctly).  The URL is
> http://svn.python.org/projects/external/
>
> Not only does this mandate an additional dependency to run a Windows
> build (I don't think we use SVN anywhere else), but it actually makes
> them unpleasantly slower, because SVN is crappy at making checkouts.
>
> Is it planned to move that repo to git?

I would very much like to move away from hosting these things on
svn.p.o, but haven't yet had time to figure out the best way to do so,
let alone get it done.  I've considered doing shallow checkouts of a
Git repository set up very much like svn.p.o/projects/external, doing
some manner of black magic with Git submodules, or just downloading
source tarballs and maintaining any necessary patches in the cpython
repo.  The biggest issue with the third option currently is that
Windows doesn't have a `patch` command, but it looks like `git apply`
will happily apply patches to files it doesn't track, so I'm starting
to really like that option.  Steve has expressed apprehension about
depending on external infrastructure to be able to build installers,
so we'd probably need to rehost the tarballs somewhere rather than
downloading from their distributors.

-- 
Zach

From solipsis at pitrou.net  Wed Dec  7 17:40:20 2016
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 7 Dec 2016 23:40:20 +0100
Subject: [core-workflow] Fate of SVN externals
References: <20161207213940.42245cd5@fsol>
 <CAKJDb-O3ySC+Ks+S5bkmbc3K9_HYNAgtMDE7KcutCfn4NrrC2A@mail.gmail.com>
Message-ID: <20161207234020.0d04fe9f@fsol>

On Wed, 7 Dec 2016 15:17:20 -0600
Zachary Ware
<zachary.ware+pydev at gmail.com> wrote:
> 
> I would very much like to move away from hosting these things on
> svn.p.o, but haven't yet had time to figure out the best way to do so,
> let alone get it done.  I've considered doing shallow checkouts of a
> Git repository set up very much like svn.p.o/projects/external, doing
> some manner of black magic with Git submodules,

I'm not sure you need some manner of black magic with Git submodules.
Just maintain the externals as individual directories in the said Git
repo?

Regards

Antoine.



From brett at python.org  Fri Dec  9 20:19:22 2016
From: brett at python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 01:19:22 +0000
Subject: [core-workflow] New core-workflow issue tracker
Message-ID: <CAP1=2W6EO9yJK0s0sV7fmX4hT84bqQ9sgm1iDCZwK+h6tGMYMA@mail.gmail.com>

I have created https://github.com/python/core-workflow to track ideas and
plans related to this mailing list. Figured that while this list is nice
for discussion an issue tracker was needed to track is actually planned.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161210/a1e8c5b9/attachment.html>

From ncoghlan at gmail.com  Fri Dec  9 22:59:14 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 10 Dec 2016 13:59:14 +1000
Subject: [core-workflow] New core-workflow issue tracker
In-Reply-To: <CAP1=2W6EO9yJK0s0sV7fmX4hT84bqQ9sgm1iDCZwK+h6tGMYMA@mail.gmail.com>
References: <CAP1=2W6EO9yJK0s0sV7fmX4hT84bqQ9sgm1iDCZwK+h6tGMYMA@mail.gmail.com>
Message-ID: <CADiSq7c7s2JNovr=2AgUVrr-knHhx_RbjWLnk_5N8yjm2s0K+A@mail.gmail.com>

On 10 December 2016 at 11:19, Brett Cannon <brett at python.org> wrote:
> I have created https://github.com/python/core-workflow to track ideas and
> plans related to this mailing list. Figured that while this list is nice for
> discussion an issue tracker was needed to track is actually planned.

Makes sense to me. If you're so inclined, you may also want to take a
look at https://waffle.io/ as a possible way of visualising work in
progress.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From donald at stufft.io  Fri Dec  9 23:00:42 2016
From: donald at stufft.io (Donald Stufft)
Date: Fri, 9 Dec 2016 23:00:42 -0500
Subject: [core-workflow] New core-workflow issue tracker
In-Reply-To: <CADiSq7c7s2JNovr=2AgUVrr-knHhx_RbjWLnk_5N8yjm2s0K+A@mail.gmail.com>
References: <CAP1=2W6EO9yJK0s0sV7fmX4hT84bqQ9sgm1iDCZwK+h6tGMYMA@mail.gmail.com>
 <CADiSq7c7s2JNovr=2AgUVrr-knHhx_RbjWLnk_5N8yjm2s0K+A@mail.gmail.com>
Message-ID: <A5E7C3E9-B647-44A9-9802-6683EAB173D8@stufft.io>



> On Dec 9, 2016, at 10:59 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 10 December 2016 at 11:19, Brett Cannon <brett at python.org> wrote:
>> I have created https://github.com/python/core-workflow to track ideas and
>> plans related to this mailing list. Figured that while this list is nice for
>> discussion an issue tracker was needed to track is actually planned.
> 
> Makes sense to me. If you're so inclined, you may also want to take a
> look at https://waffle.io/ as a possible way of visualising work in
> progress.



Github recently added their own feature similar to this called ?Projects? as well - https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and-features <https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and-features>

?
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161209/118d9402/attachment.html>

From ncoghlan at gmail.com  Fri Dec  9 23:40:08 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 10 Dec 2016 14:40:08 +1000
Subject: [core-workflow] New core-workflow issue tracker
In-Reply-To: <A5E7C3E9-B647-44A9-9802-6683EAB173D8@stufft.io>
References: <CAP1=2W6EO9yJK0s0sV7fmX4hT84bqQ9sgm1iDCZwK+h6tGMYMA@mail.gmail.com>
 <CADiSq7c7s2JNovr=2AgUVrr-knHhx_RbjWLnk_5N8yjm2s0K+A@mail.gmail.com>
 <A5E7C3E9-B647-44A9-9802-6683EAB173D8@stufft.io>
Message-ID: <CADiSq7cxkVxEyJJEZvfGM=tbyaOyU_bwv6HpbeuWujcw9SfxVA@mail.gmail.com>

On 10 December 2016 at 14:00, Donald Stufft <donald at stufft.io> wrote:
> Github recently added their own feature similar to this called ?Projects? as
> well -
> https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and-features

Ah, nice - and handy since it avoids creating an extra org account in
another service.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From brett at python.org  Sat Dec 10 00:29:46 2016
From: brett at python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 05:29:46 +0000
Subject: [core-workflow] New core-workflow issue tracker
In-Reply-To: <CADiSq7cxkVxEyJJEZvfGM=tbyaOyU_bwv6HpbeuWujcw9SfxVA@mail.gmail.com>
References: <CAP1=2W6EO9yJK0s0sV7fmX4hT84bqQ9sgm1iDCZwK+h6tGMYMA@mail.gmail.com>
 <CADiSq7c7s2JNovr=2AgUVrr-knHhx_RbjWLnk_5N8yjm2s0K+A@mail.gmail.com>
 <A5E7C3E9-B647-44A9-9802-6683EAB173D8@stufft.io>
 <CADiSq7cxkVxEyJJEZvfGM=tbyaOyU_bwv6HpbeuWujcw9SfxVA@mail.gmail.com>
Message-ID: <CAP1=2W6OBnjc=+0dqre7WB45FuugJ+MEQD8doWEgGkWjRHyCQg@mail.gmail.com>

I'm trying Projects out in the peps repo. You can also create projects
either repo or org level.

On Fri, Dec 9, 2016, 20:40 Nick Coghlan, <ncoghlan at gmail.com> wrote:

> On 10 December 2016 at 14:00, Donald Stufft <donald at stufft.io> wrote:
> > Github recently added their own feature similar to this called
> ?Projects? as
> > well -
> >
> https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and-features
>
> Ah, nice - and handy since it avoids creating an extra org account in
> another service.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161210/6fbb0505/attachment-0001.html>

From brett at python.org  Fri Dec 16 13:49:05 2016
From: brett at python.org (Brett Cannon)
Date: Fri, 16 Dec 2016 18:49:05 +0000
Subject: [core-workflow] Windows of opportunity to do the GitHub migration
Message-ID: <CAP1=2W6TSe7tRT7SP_62CX=vJadBg7RhMGZgKWxy+uuVBX+WCw@mail.gmail.com>

[sending this independently to python-dev and core-workflow]

I have promised Ned that we will not migrate before 3.6.0 is released and
not for a week following in case an emergency 3.6.1 is necessary. I also
promised Larry we wouldn't migrate the week before 3.5.3 is released. That
means the windows for migrating are 2016-12-30 to 2017-01-09, and then any
time after 2016-01-16 (this of course assumes all release schedules don't
slip).

I'm now on vacation until January 3 so I will have time to work on the
migration some more. I will port hg.python.org/lookup to work with git, hg,
and svn probably this week or next. That leaves the only true blockers as
http://psf.upfronthosting.co.za/roundup/meta/issue589 and
http://psf.upfronthosting.co.za/roundup/meta/issue590 (webhook for PR to
issue and notifying an issue when a commit has occurred, respectively; we
already have a GitHub PR field on b.p.o for manual entry). Once those
changes to bugs.python.org land and have been tested live against the
GitHub mirror, we can do the migration (which will most likely take a day
or two). All other issues either require the repo to have already been
migrated and working or can wait post-migration (
https://www.python.org/dev/peps/pep-0512/#cpython-repo).

So if the above wasn't clear, if you want to help then please help with the
b.p.o issues as those are the remaining blockers I can't deal with on my
own. And I actually have GitHub-themed gifts I bought myself sitting under
my Xmas tree that I won't open until we migrate, so let's not take too
long. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161216/c5716ddf/attachment.html>

From soltysh at gmail.com  Fri Dec 16 17:24:22 2016
From: soltysh at gmail.com (Maciej Szulik)
Date: Fri, 16 Dec 2016 23:24:22 +0100
Subject: [core-workflow] Windows of opportunity to do the GitHub
 migration
In-Reply-To: <CAP1=2W6TSe7tRT7SP_62CX=vJadBg7RhMGZgKWxy+uuVBX+WCw@mail.gmail.com>
References: <CAP1=2W6TSe7tRT7SP_62CX=vJadBg7RhMGZgKWxy+uuVBX+WCw@mail.gmail.com>
Message-ID: <CALC2N4aBR52dUTn8Rh82NuM6+M=2spwg5fcxJnWURQjmyS8EoQ@mail.gmail.com>

On Fri, Dec 16, 2016 at 7:49 PM, Brett Cannon <brett at python.org> wrote:

> [sending this independently to python-dev and core-workflow]
>
> I have promised Ned that we will not migrate before 3.6.0 is released and
> not for a week following in case an emergency 3.6.1 is necessary. I also
> promised Larry we wouldn't migrate the week before 3.5.3 is released. That
> means the windows for migrating are 2016-12-30 to 2017-01-09, and then any
> time after 2016-01-16 (this of course assumes all release schedules don't
> slip).
>
> I'm now on vacation until January 3 so I will have time to work on the
> migration some more. I will port hg.python.org/lookup to work with git,
> hg, and svn probably this week or next. That leaves the only true blockers
> as http://psf.upfronthosting.co.za/roundup/meta/issue589 and
> http://psf.upfronthosting.co.za/roundup/meta/issue590 (webhook for PR to
> issue and notifying an issue when a commit has occurred, respectively; we
> already have a GitHub PR field on b.p.o for manual entry). Once those
> changes to bugs.python.org land and have been tested live against the
> GitHub mirror, we can do the migration (which will most likely take a day
> or two). All other issues either require the repo to have already been
> migrated and working or can wait post-migration (
> https://www.python.org/dev/peps/pep-0512/#cpython-repo).
>

I'm testing issue589 as I'm writing this, hopefully I should be able to
finish all the test and hand it over to Ezio
over this weekend. Then I'll start looking into 590, although the latter
will be much simpler when 589 is in place,
since it just builds on what we already have (github field) and 589.


>
> So if the above wasn't clear, if you want to help then please help with
> the b.p.o issues as those are the remaining blockers I can't deal with on
> my own. And I actually have GitHub-themed gifts I bought myself sitting
> under my Xmas tree that I won't open until we migrate, so let's not take
> too long. ;)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161216/89641915/attachment.html>

From brett at python.org  Fri Dec 16 20:58:36 2016
From: brett at python.org (Brett Cannon)
Date: Sat, 17 Dec 2016 01:58:36 +0000
Subject: [core-workflow] Windows of opportunity to do the GitHub
 migration
In-Reply-To: <CALC2N4aBR52dUTn8Rh82NuM6+M=2spwg5fcxJnWURQjmyS8EoQ@mail.gmail.com>
References: <CAP1=2W6TSe7tRT7SP_62CX=vJadBg7RhMGZgKWxy+uuVBX+WCw@mail.gmail.com>
 <CALC2N4aBR52dUTn8Rh82NuM6+M=2spwg5fcxJnWURQjmyS8EoQ@mail.gmail.com>
Message-ID: <CAP1=2W66BZeO==XLeY55XSeHdL1eg_zzcua2M=V1tFqBmydLzA@mail.gmail.com>

Thanks for the update (and sorry for relying on you and Ezio so much for
this stuff; really appreciate the help!).

On Fri, 16 Dec 2016 at 14:24 Maciej Szulik <soltysh at gmail.com> wrote:

> On Fri, Dec 16, 2016 at 7:49 PM, Brett Cannon <brett at python.org> wrote:
>
> [sending this independently to python-dev and core-workflow]
>
> I have promised Ned that we will not migrate before 3.6.0 is released and
> not for a week following in case an emergency 3.6.1 is necessary. I also
> promised Larry we wouldn't migrate the week before 3.5.3 is released. That
> means the windows for migrating are 2016-12-30 to 2017-01-09, and then any
> time after 2016-01-16 (this of course assumes all release schedules don't
> slip).
>
> I'm now on vacation until January 3 so I will have time to work on the
> migration some more. I will port hg.python.org/lookup to work with git,
> hg, and svn probably this week or next. That leaves the only true blockers
> as http://psf.upfronthosting.co.za/roundup/meta/issue589 and
> http://psf.upfronthosting.co.za/roundup/meta/issue590 (webhook for PR to
> issue and notifying an issue when a commit has occurred, respectively; we
> already have a GitHub PR field on b.p.o for manual entry). Once those
> changes to bugs.python.org land and have been tested live against the
> GitHub mirror, we can do the migration (which will most likely take a day
> or two). All other issues either require the repo to have already been
> migrated and working or can wait post-migration (
> https://www.python.org/dev/peps/pep-0512/#cpython-repo).
>
>
> I'm testing issue589 as I'm writing this, hopefully I should be able to
> finish all the test and hand it over to Ezio
> over this weekend. Then I'll start looking into 590, although the latter
> will be much simpler when 589 is in place,
> since it just builds on what we already have (github field) and 589.
>
>
>
> So if the above wasn't clear, if you want to help then please help with
> the b.p.o issues as those are the remaining blockers I can't deal with on
> my own. And I actually have GitHub-themed gifts I bought myself sitting
> under my Xmas tree that I won't open until we migrate, so let's not take
> too long. ;)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161217/fbb75b13/attachment-0001.html>

From soltysh at gmail.com  Sat Dec 17 14:51:57 2016
From: soltysh at gmail.com (Maciej Szulik)
Date: Sat, 17 Dec 2016 20:51:57 +0100
Subject: [core-workflow] Windows of opportunity to do the GitHub
 migration
In-Reply-To: <CAP1=2W66BZeO==XLeY55XSeHdL1eg_zzcua2M=V1tFqBmydLzA@mail.gmail.com>
References: <CAP1=2W6TSe7tRT7SP_62CX=vJadBg7RhMGZgKWxy+uuVBX+WCw@mail.gmail.com>
 <CALC2N4aBR52dUTn8Rh82NuM6+M=2spwg5fcxJnWURQjmyS8EoQ@mail.gmail.com>
 <CAP1=2W66BZeO==XLeY55XSeHdL1eg_zzcua2M=V1tFqBmydLzA@mail.gmail.com>
Message-ID: <CALC2N4bKf=k9XEzkYTxPzB81A9Rn3gPq8d=rYPcGSPBo3NMjDw@mail.gmail.com>

It's a pleasure for me! Finally, I can have a significant contribution to
python :)

Maciej

On Sat, Dec 17, 2016 at 2:58 AM, Brett Cannon <brett at python.org> wrote:

> Thanks for the update (and sorry for relying on you and Ezio so much for
> this stuff; really appreciate the help!).
>
> On Fri, 16 Dec 2016 at 14:24 Maciej Szulik <soltysh at gmail.com> wrote:
>
>> On Fri, Dec 16, 2016 at 7:49 PM, Brett Cannon <brett at python.org> wrote:
>>
>> [sending this independently to python-dev and core-workflow]
>>
>> I have promised Ned that we will not migrate before 3.6.0 is released and
>> not for a week following in case an emergency 3.6.1 is necessary. I also
>> promised Larry we wouldn't migrate the week before 3.5.3 is released. That
>> means the windows for migrating are 2016-12-30 to 2017-01-09, and then any
>> time after 2016-01-16 (this of course assumes all release schedules don't
>> slip).
>>
>> I'm now on vacation until January 3 so I will have time to work on the
>> migration some more. I will port hg.python.org/lookup to work with git,
>> hg, and svn probably this week or next. That leaves the only true blockers
>> as http://psf.upfronthosting.co.za/roundup/meta/issue589 and
>> http://psf.upfronthosting.co.za/roundup/meta/issue590 (webhook for PR to
>> issue and notifying an issue when a commit has occurred, respectively; we
>> already have a GitHub PR field on b.p.o for manual entry). Once those
>> changes to bugs.python.org land and have been tested live against the
>> GitHub mirror, we can do the migration (which will most likely take a day
>> or two). All other issues either require the repo to have already been
>> migrated and working or can wait post-migration (
>> https://www.python.org/dev/peps/pep-0512/#cpython-repo).
>>
>>
>> I'm testing issue589 as I'm writing this, hopefully I should be able to
>> finish all the test and hand it over to Ezio
>> over this weekend. Then I'll start looking into 590, although the latter
>> will be much simpler when 589 is in place,
>> since it just builds on what we already have (github field) and 589.
>>
>>
>>
>> So if the above wasn't clear, if you want to help then please help with
>> the b.p.o issues as those are the remaining blockers I can't deal with on
>> my own. And I actually have GitHub-themed gifts I bought myself sitting
>> under my Xmas tree that I won't open until we migrate, so let's not take
>> too long. ;)
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161217/76e19e43/attachment.html>

From brett at python.org  Mon Dec 19 21:49:03 2016
From: brett at python.org (Brett Cannon)
Date: Tue, 20 Dec 2016 02:49:03 +0000
Subject: [core-workflow] GitHub migration update for 2016-12-19
Message-ID: <CAP1=2W6GoE2aEVkqiJPf3wqkdSgJZYu2AwnfGMORkQ9Jz+jKuA@mail.gmail.com>

The biggest update is I have updated the code for hg.python.org/lookup.
Once the hg repo is read-only I will generate a final JSON file containing
every commit and then have the new code and data uploaded. If you want to
look at the modified code and double-check my work then please look at
https://gist.github.com/brettcannon/f8d97c92b0df264cd4db008ffd32daf9.

I have also added a TODO to make sure the docs will build from git (kind of
an important thing :) ). I'll reach out to the appropriate people to see
what that will take.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161220/3968c42c/attachment.html>

From solipsis at pitrou.net  Tue Dec 20 02:49:36 2016
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 20 Dec 2016 08:49:36 +0100
Subject: [core-workflow] GitHub migration update for 2016-12-19
References: <CAP1=2W6GoE2aEVkqiJPf3wqkdSgJZYu2AwnfGMORkQ9Jz+jKuA@mail.gmail.com>
Message-ID: <20161220084936.3ea98a4b@fsol>

On Tue, 20 Dec 2016 02:49:03 +0000
Brett Cannon <brett at python.org> wrote:
> The biggest update is I have updated the code for hg.python.org/lookup.
> Once the hg repo is read-only I will generate a final JSON file containing
> every commit and then have the new code and data uploaded. If you want to
> look at the modified code and double-check my work then please look at
> https://gist.github.com/brettcannon/f8d97c92b0df264cd4db008ffd32daf9.

I thought you were going to redirect hg changeset references to github,
so that we don't have to maintain hg.p.o indefinitely.

Ditto for SVN revision references (which currently are redirected to
hg.p.o, not svn.p.o).

Regards

Antoine.



From brett at python.org  Tue Dec 20 12:46:52 2016
From: brett at python.org (Brett Cannon)
Date: Tue, 20 Dec 2016 17:46:52 +0000
Subject: [core-workflow] GitHub migration update for 2016-12-19
In-Reply-To: <20161220084936.3ea98a4b@fsol>
References: <CAP1=2W6GoE2aEVkqiJPf3wqkdSgJZYu2AwnfGMORkQ9Jz+jKuA@mail.gmail.com>
 <20161220084936.3ea98a4b@fsol>
Message-ID: <CAP1=2W408ZkecVPOXbY7hU2VFkFTsX4QyLWCs_T8AMmAAgMEfQ@mail.gmail.com>

Long-term yes, but I'm under time pressure here and with no one helping me
deal with this problem I went with the easiest solution that I knew
wouldn't break unexpectedly (hence the simplification for mapping svn
changesets to svn.python.org and not keeping all the code around to map to
hg.python.org).

On Mon, 19 Dec 2016 at 23:49 Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Tue, 20 Dec 2016 02:49:03 +0000
> Brett Cannon <brett at python.org> wrote:
> > The biggest update is I have updated the code for hg.python.org/lookup.
> > Once the hg repo is read-only I will generate a final JSON file
> containing
> > every commit and then have the new code and data uploaded. If you want to
> > look at the modified code and double-check my work then please look at
> > https://gist.github.com/brettcannon/f8d97c92b0df264cd4db008ffd32daf9.
>
> I thought you were going to redirect hg changeset references to github,
> so that we don't have to maintain hg.p.o indefinitely.
>
> Ditto for SVN revision references (which currently are redirected to
> hg.p.o, not svn.p.o).
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161220/fd5516a1/attachment.html>

From ncoghlan at gmail.com  Tue Dec 20 19:14:36 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 21 Dec 2016 10:14:36 +1000
Subject: [core-workflow] GitHub migration update for 2016-12-19
In-Reply-To: <CAP1=2W408ZkecVPOXbY7hU2VFkFTsX4QyLWCs_T8AMmAAgMEfQ@mail.gmail.com>
References: <CAP1=2W6GoE2aEVkqiJPf3wqkdSgJZYu2AwnfGMORkQ9Jz+jKuA@mail.gmail.com>
 <20161220084936.3ea98a4b@fsol>
 <CAP1=2W408ZkecVPOXbY7hU2VFkFTsX4QyLWCs_T8AMmAAgMEfQ@mail.gmail.com>
Message-ID: <CADiSq7dTyaLGrFk1agXREB_M_m-BiaAT3rdoqxWOHpekJpOW2g@mail.gmail.com>

On 21 December 2016 at 03:46, Brett Cannon <brett at python.org> wrote:

> Long-term yes, but I'm under time pressure here and with no one helping me
> deal with this problem I went with the easiest solution that I knew
> wouldn't break unexpectedly (hence the simplification for mapping svn
> changesets to svn.python.org and not keeping all the code around to map
> to hg.python.org).
>

It's also one of those things where redirecting hg & svn references to the
matching git commits is only a requirement if and when we *do* decide to
shut off the old servers, which would break a *lot* of links in mailing
list archives, Stack Overflow, blog posts, etc.

Once we get to the point where all remote write access to both servers has
been shut off, a link-preserving, maintenance-reducing solution might be to
bake both the repository data and the corresponding web gateway software
into a pair of Linux container images and then host them wherever is
easiest for the PSF infrastructure team.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161221/7655344f/attachment.html>

From soltysh at gmail.com  Wed Dec 21 06:05:43 2016
From: soltysh at gmail.com (Maciej Szulik)
Date: Wed, 21 Dec 2016 12:05:43 +0100
Subject: [core-workflow] GitHub migration update for 2016-12-19
In-Reply-To: <CADiSq7dTyaLGrFk1agXREB_M_m-BiaAT3rdoqxWOHpekJpOW2g@mail.gmail.com>
References: <CAP1=2W6GoE2aEVkqiJPf3wqkdSgJZYu2AwnfGMORkQ9Jz+jKuA@mail.gmail.com>
 <20161220084936.3ea98a4b@fsol>
 <CAP1=2W408ZkecVPOXbY7hU2VFkFTsX4QyLWCs_T8AMmAAgMEfQ@mail.gmail.com>
 <CADiSq7dTyaLGrFk1agXREB_M_m-BiaAT3rdoqxWOHpekJpOW2g@mail.gmail.com>
Message-ID: <CALC2N4ZFOn0L3EwF3HoKTn-8xYeLDEkt22HXUS-UtAtpvYvZLw@mail.gmail.com>

On Wed, Dec 21, 2016 at 1:14 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 21 December 2016 at 03:46, Brett Cannon <brett at python.org> wrote:
>
>> Long-term yes, but I'm under time pressure here and with no one helping
>> me deal with this problem I went with the easiest solution that I knew
>> wouldn't break unexpectedly (hence the simplification for mapping svn
>> changesets to svn.python.org and not keeping all the code around to map
>> to hg.python.org).
>>
>
> It's also one of those things where redirecting hg & svn references to the
> matching git commits is only a requirement if and when we *do* decide to
> shut off the old servers, which would break a *lot* of links in mailing
> list archives, Stack Overflow, blog posts, etc.
>
> Once we get to the point where all remote write access to both servers has
> been shut off, a link-preserving, maintenance-reducing solution might be to
> bake both the repository data and the corresponding web gateway software
> into a pair of Linux container images and then host them wherever is
> easiest for the PSF infrastructure team.
>
>
Not sure how much it's doable, but I can help with that. Once we can create
a commit mapping between
hg, svn and git repo it would be nice to put that in front of svn.p.o and
hg.p.o and redirect to git.
At least it'll teach people that we're on git and this is where they should
look by default.
Yes, that means I'm volunteering to help with that :)

Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161221/18c71ffb/attachment.html>

From brett at python.org  Wed Dec 21 12:19:50 2016
From: brett at python.org (Brett Cannon)
Date: Wed, 21 Dec 2016 17:19:50 +0000
Subject: [core-workflow] GitHub migration update for 2016-12-19
In-Reply-To: <CALC2N4ZFOn0L3EwF3HoKTn-8xYeLDEkt22HXUS-UtAtpvYvZLw@mail.gmail.com>
References: <CAP1=2W6GoE2aEVkqiJPf3wqkdSgJZYu2AwnfGMORkQ9Jz+jKuA@mail.gmail.com>
 <20161220084936.3ea98a4b@fsol>
 <CAP1=2W408ZkecVPOXbY7hU2VFkFTsX4QyLWCs_T8AMmAAgMEfQ@mail.gmail.com>
 <CADiSq7dTyaLGrFk1agXREB_M_m-BiaAT3rdoqxWOHpekJpOW2g@mail.gmail.com>
 <CALC2N4ZFOn0L3EwF3HoKTn-8xYeLDEkt22HXUS-UtAtpvYvZLw@mail.gmail.com>
Message-ID: <CAP1=2W5SQZ6gGdyfZjho0j=DPB-px_c6pNJVrmjOJ_nt+BsFWg@mail.gmail.com>

Thanks, Maciej! I created https://github.com/python/core-workflow/issues/12 to
track this. If you reply there with your GitHub account I can add you as a
collaborator on the project and assign it to you properly.

On Wed, 21 Dec 2016 at 03:05 Maciej Szulik <soltysh at gmail.com> wrote:

> On Wed, Dec 21, 2016 at 1:14 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 21 December 2016 at 03:46, Brett Cannon <brett at python.org> wrote:
>
> Long-term yes, but I'm under time pressure here and with no one helping me
> deal with this problem I went with the easiest solution that I knew
> wouldn't break unexpectedly (hence the simplification for mapping svn
> changesets to svn.python.org and not keeping all the code around to map
> to hg.python.org).
>
>
> It's also one of those things where redirecting hg & svn references to the
> matching git commits is only a requirement if and when we *do* decide to
> shut off the old servers, which would break a *lot* of links in mailing
> list archives, Stack Overflow, blog posts, etc.
>
> Once we get to the point where all remote write access to both servers has
> been shut off, a link-preserving, maintenance-reducing solution might be to
> bake both the repository data and the corresponding web gateway software
> into a pair of Linux container images and then host them wherever is
> easiest for the PSF infrastructure team.
>
>
> Not sure how much it's doable, but I can help with that. Once we can
> create a commit mapping between
> hg, svn and git repo it would be nice to put that in front of svn.p.o and
> hg.p.o and redirect to git.
> At least it'll teach people that we're on git and this is where they
> should look by default.
> Yes, that means I'm volunteering to help with that :)
>
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161221/ef200a0f/attachment.html>

From soltysh at gmail.com  Wed Dec 21 16:29:57 2016
From: soltysh at gmail.com (Maciej Szulik)
Date: Wed, 21 Dec 2016 22:29:57 +0100
Subject: [core-workflow] GitHub migration update for 2016-12-19
In-Reply-To: <CAP1=2W5SQZ6gGdyfZjho0j=DPB-px_c6pNJVrmjOJ_nt+BsFWg@mail.gmail.com>
References: <CAP1=2W6GoE2aEVkqiJPf3wqkdSgJZYu2AwnfGMORkQ9Jz+jKuA@mail.gmail.com>
 <20161220084936.3ea98a4b@fsol>
 <CAP1=2W408ZkecVPOXbY7hU2VFkFTsX4QyLWCs_T8AMmAAgMEfQ@mail.gmail.com>
 <CADiSq7dTyaLGrFk1agXREB_M_m-BiaAT3rdoqxWOHpekJpOW2g@mail.gmail.com>
 <CALC2N4ZFOn0L3EwF3HoKTn-8xYeLDEkt22HXUS-UtAtpvYvZLw@mail.gmail.com>
 <CAP1=2W5SQZ6gGdyfZjho0j=DPB-px_c6pNJVrmjOJ_nt+BsFWg@mail.gmail.com>
Message-ID: <CALC2N4au2d9TVSwKJYxxx_qqwVK-fLU_jSLxCX=qcyACrPuNsQ@mail.gmail.com>

I go under soltysh everywhere where possible ;)

On Wed, Dec 21, 2016 at 6:19 PM, Brett Cannon <brett at python.org> wrote:

> Thanks, Maciej! I created https://github.com/
> python/core-workflow/issues/12 to track this. If you reply there with
> your GitHub account I can add you as a collaborator on the project and
> assign it to you properly.
>
> On Wed, 21 Dec 2016 at 03:05 Maciej Szulik <soltysh at gmail.com> wrote:
>
>> On Wed, Dec 21, 2016 at 1:14 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> On 21 December 2016 at 03:46, Brett Cannon <brett at python.org> wrote:
>>
>> Long-term yes, but I'm under time pressure here and with no one helping
>> me deal with this problem I went with the easiest solution that I knew
>> wouldn't break unexpectedly (hence the simplification for mapping svn
>> changesets to svn.python.org and not keeping all the code around to map
>> to hg.python.org).
>>
>>
>> It's also one of those things where redirecting hg & svn references to
>> the matching git commits is only a requirement if and when we *do* decide
>> to shut off the old servers, which would break a *lot* of links in mailing
>> list archives, Stack Overflow, blog posts, etc.
>>
>> Once we get to the point where all remote write access to both servers
>> has been shut off, a link-preserving, maintenance-reducing solution might
>> be to bake both the repository data and the corresponding web gateway
>> software into a pair of Linux container images and then host them wherever
>> is easiest for the PSF infrastructure team.
>>
>>
>> Not sure how much it's doable, but I can help with that. Once we can
>> create a commit mapping between
>> hg, svn and git repo it would be nice to put that in front of svn.p.o and
>> hg.p.o and redirect to git.
>> At least it'll teach people that we're on git and this is where they
>> should look by default.
>> Yes, that means I'm volunteering to help with that :)
>>
>> Maciej
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161221/35075276/attachment.html>

From ezio.melotti at gmail.com  Thu Dec 22 22:12:52 2016
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Fri, 23 Dec 2016 04:12:52 +0100
Subject: [core-workflow] GitHub migration update for 2016-12-19
In-Reply-To: <20161220084936.3ea98a4b@fsol>
References: <CAP1=2W6GoE2aEVkqiJPf3wqkdSgJZYu2AwnfGMORkQ9Jz+jKuA@mail.gmail.com>
 <20161220084936.3ea98a4b@fsol>
Message-ID: <CACBhJdH+a07pdxp1vmNedRR4xbNb5uB=oxuL=suRbomGO5R1Xg@mail.gmail.com>

On Tue, Dec 20, 2016 at 8:49 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 20 Dec 2016 02:49:03 +0000
> Brett Cannon <brett at python.org> wrote:
>> The biggest update is I have updated the code for hg.python.org/lookup.
>> Once the hg repo is read-only I will generate a final JSON file containing
>> every commit and then have the new code and data uploaded. If you want to
>> look at the modified code and double-check my work then please look at
>> https://gist.github.com/brettcannon/f8d97c92b0df264cd4db008ffd32daf9.
>
> I thought you were going to redirect hg changeset references to github,
> so that we don't have to maintain hg.p.o indefinitely.
>

The Roundup that we are using on b.p.o[0] is a clone of upstream
Roundup[1] with our additional changes[2] in a separate branch.

There are 4 things that could happen to this repo:
  1. keep hg.p.o alive and nothing changes;
  2. move it somewhere else (e.g. BitBucket -- does GitHub support HG repos?);
  3. convert it to Git and move it to GitHub with the others;
  4. get rid of our branch and use a regular Roundup;

As long as we keep it on HG (whether on hg.p.o or BitBucket), updating
it is a matter of a pull/merge/push.  If we port it to Git, updating
will become less straightforward, but probably still doable.  Getting
rid of our branch means reviewing and porting upstream our changes,
then wait for the next official Roundup release and use that.  Note
that some of the upcoming changes we are working on while integrating
b.p.o with GitHub also affect Roundup, so they will make our branch
diverge further.

The instances (b.p.o, the meta-tracker, and the others) could
technically be converted to Git, but I would rather keep them together
with our Roundup clone.

Best Regards,
Ezio Melotti

[0]: https://hg.python.org/tracker/roundup/
[1]: http://hg.code.sf.net/p/roundup/code
[2]: more on the differences in this thread:
https://sourceforge.net/p/roundup/mailman/message/30752855/

> Ditto for SVN revision references (which currently are redirected to
> hg.p.o, not svn.p.o).
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

From brett at python.org  Thu Dec 22 22:45:22 2016
From: brett at python.org (Brett Cannon)
Date: Fri, 23 Dec 2016 03:45:22 +0000
Subject: [core-workflow] GitHub migration update for 2016-12-19
In-Reply-To: <CACBhJdH+a07pdxp1vmNedRR4xbNb5uB=oxuL=suRbomGO5R1Xg@mail.gmail.com>
References: <CAP1=2W6GoE2aEVkqiJPf3wqkdSgJZYu2AwnfGMORkQ9Jz+jKuA@mail.gmail.com>
 <20161220084936.3ea98a4b@fsol>
 <CACBhJdH+a07pdxp1vmNedRR4xbNb5uB=oxuL=suRbomGO5R1Xg@mail.gmail.com>
Message-ID: <CAP1=2W5FmT0ik=2M0cC84FaesDbUOae48m_MgEgNmMb=yMo0UA@mail.gmail.com>

My assumption has been that when we close hg.p.o -- which is a ways off --
that the repo would move to Bitbucket.

On Thu, Dec 22, 2016, 19:13 Ezio Melotti, <ezio.melotti at gmail.com> wrote:

> On Tue, Dec 20, 2016 at 8:49 AM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
> > On Tue, 20 Dec 2016 02:49:03 +0000
> > Brett Cannon <brett at python.org> wrote:
> >> The biggest update is I have updated the code for hg.python.org/lookup.
> >> Once the hg repo is read-only I will generate a final JSON file
> containing
> >> every commit and then have the new code and data uploaded. If you want
> to
> >> look at the modified code and double-check my work then please look at
> >> https://gist.github.com/brettcannon/f8d97c92b0df264cd4db008ffd32daf9.
> >
> > I thought you were going to redirect hg changeset references to github,
> > so that we don't have to maintain hg.p.o indefinitely.
> >
>
> The Roundup that we are using on b.p.o[0] is a clone of upstream
> Roundup[1] with our additional changes[2] in a separate branch.
>
> There are 4 things that could happen to this repo:
>   1. keep hg.p.o alive and nothing changes;
>   2. move it somewhere else (e.g. BitBucket -- does GitHub support HG
> repos?);
>   3. convert it to Git and move it to GitHub with the others;
>   4. get rid of our branch and use a regular Roundup;
>
> As long as we keep it on HG (whether on hg.p.o or BitBucket), updating
> it is a matter of a pull/merge/push.  If we port it to Git, updating
> will become less straightforward, but probably still doable.  Getting
> rid of our branch means reviewing and porting upstream our changes,
> then wait for the next official Roundup release and use that.  Note
> that some of the upcoming changes we are working on while integrating
> b.p.o with GitHub also affect Roundup, so they will make our branch
> diverge further.
>
> The instances (b.p.o, the meta-tracker, and the others) could
> technically be converted to Git, but I would rather keep them together
> with our Roundup clone.
>
> Best Regards,
> Ezio Melotti
>
> [0]: https://hg.python.org/tracker/roundup/
> [1]: http://hg.code.sf.net/p/roundup/code
> [2]: more on the differences in this thread:
> https://sourceforge.net/p/roundup/mailman/message/30752855/
>
> > Ditto for SVN revision references (which currently are redirected to
> > hg.p.o, not svn.p.o).
> >
> > Regards
> >
> > Antoine.
> >
> >
> > _______________________________________________
> > core-workflow mailing list
> > core-workflow at python.org
> > https://mail.python.org/mailman/listinfo/core-workflow
> > This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161223/3f58e5a7/attachment.html>

From ezio.melotti at gmail.com  Thu Dec 22 23:30:46 2016
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Fri, 23 Dec 2016 05:30:46 +0100
Subject: [core-workflow] GitHub migration update for 2016-12-19
In-Reply-To: <CAP1=2W5FmT0ik=2M0cC84FaesDbUOae48m_MgEgNmMb=yMo0UA@mail.gmail.com>
References: <CAP1=2W6GoE2aEVkqiJPf3wqkdSgJZYu2AwnfGMORkQ9Jz+jKuA@mail.gmail.com>
 <20161220084936.3ea98a4b@fsol>
 <CACBhJdH+a07pdxp1vmNedRR4xbNb5uB=oxuL=suRbomGO5R1Xg@mail.gmail.com>
 <CAP1=2W5FmT0ik=2M0cC84FaesDbUOae48m_MgEgNmMb=yMo0UA@mail.gmail.com>
Message-ID: <CACBhJdHSRmeo3=TDQY6YQa8eDuvUhN1cn=sfw7_zkLFASvnrcA@mail.gmail.com>

That works.

On Fri, Dec 23, 2016 at 4:45 AM, Brett Cannon <brett at python.org> wrote:
> My assumption has been that when we close hg.p.o -- which is a ways off --
> that the repo would move to Bitbucket.
>
>
> On Thu, Dec 22, 2016, 19:13 Ezio Melotti, <ezio.melotti at gmail.com> wrote:
>>
>> On Tue, Dec 20, 2016 at 8:49 AM, Antoine Pitrou <solipsis at pitrou.net>
>> wrote:
>> > On Tue, 20 Dec 2016 02:49:03 +0000
>> > Brett Cannon <brett at python.org> wrote:
>> >> The biggest update is I have updated the code for hg.python.org/lookup.
>> >> Once the hg repo is read-only I will generate a final JSON file
>> >> containing
>> >> every commit and then have the new code and data uploaded. If you want
>> >> to
>> >> look at the modified code and double-check my work then please look at
>> >> https://gist.github.com/brettcannon/f8d97c92b0df264cd4db008ffd32daf9.
>> >
>> > I thought you were going to redirect hg changeset references to github,
>> > so that we don't have to maintain hg.p.o indefinitely.
>> >
>>
>> The Roundup that we are using on b.p.o[0] is a clone of upstream
>> Roundup[1] with our additional changes[2] in a separate branch.
>>
>> There are 4 things that could happen to this repo:
>>   1. keep hg.p.o alive and nothing changes;
>>   2. move it somewhere else (e.g. BitBucket -- does GitHub support HG
>> repos?);
>>   3. convert it to Git and move it to GitHub with the others;
>>   4. get rid of our branch and use a regular Roundup;
>>
>> As long as we keep it on HG (whether on hg.p.o or BitBucket), updating
>> it is a matter of a pull/merge/push.  If we port it to Git, updating
>> will become less straightforward, but probably still doable.  Getting
>> rid of our branch means reviewing and porting upstream our changes,
>> then wait for the next official Roundup release and use that.  Note
>> that some of the upcoming changes we are working on while integrating
>> b.p.o with GitHub also affect Roundup, so they will make our branch
>> diverge further.
>>
>> The instances (b.p.o, the meta-tracker, and the others) could
>> technically be converted to Git, but I would rather keep them together
>> with our Roundup clone.
>>
>> Best Regards,
>> Ezio Melotti
>>
>> [0]: https://hg.python.org/tracker/roundup/
>> [1]: http://hg.code.sf.net/p/roundup/code
>> [2]: more on the differences in this thread:
>> https://sourceforge.net/p/roundup/mailman/message/30752855/
>>
>> > Ditto for SVN revision references (which currently are redirected to
>> > hg.p.o, not svn.p.o).
>> >
>> > Regards
>> >
>> > Antoine.
>> >
>> >
>> > _______________________________________________
>> > core-workflow mailing list
>> > core-workflow at python.org
>> > https://mail.python.org/mailman/listinfo/core-workflow
>> > This list is governed by the PSF Code of Conduct:
>> > https://www.python.org/psf/codeofconduct
>> _______________________________________________
>> core-workflow mailing list
>> core-workflow at python.org
>> https://mail.python.org/mailman/listinfo/core-workflow
>> This list is governed by the PSF Code of Conduct:
>> https://www.python.org/psf/codeofconduct