On 21 December 2016 at 03:46, Brett Cannon 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@gmail.com | Brisbane, Australia

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 wrote:

On Wed, Dec 21, 2016 at 1:14 AM, Nick Coghlan wrote:

On 21 December 2016 at 03:46, Brett Cannon 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

On Tue, Dec 20, 2016 at 8:49 AM, Antoine Pitrou wrote:

On Tue, 20 Dec 2016 02:49:03 +0000 Brett Cannon 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@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

That works. On Fri, Dec 23, 2016 at 4:45 AM, Brett Cannon 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, wrote:

...

On Tue, Dec 20, 2016 at 8:49 AM, Antoine Pitrou wrote:

...

On Tue, 20 Dec 2016 02:49:03 +0000 Brett Cannon 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@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@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