Re: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration

I know you can disable issues for a repo on GitHub, but I don't think you can disable PRs, unfortunately. ___ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code

Re: [core-workflow] Reviewing/updating the README for GitHub migration?

On Fri, Apr 22, 2016 at 11:40 PM Nick Coghlan wrote: > The reason I suggest that is that with the way code hosting services like > GitHub work, the README changes from something people may read for local > development after they've already cloned the repo to instead being the main > landing page

Re: [core-workflow] Help needed: best way to convert hg repos to git?

Response from GitHub staff regarding using their Importer to import CPython: Unfortunately, the repository is too large to migrate using the importer. I’d recommend converting it to git locally using something like hg-fast-export. Due to its size, you’ll need to push t

Re: [core-workflow] Help needed: best way to convert hg repos to git?

> I'm currently trying to import to see how it looks, have been stuck at 0% for a few minutes now. Doing the same myself. Got to 73% and it restarted. Am back at 73% now. Already reached out to GitHub to make them aware of the issue. Will report here when/if I have results. Nick ___

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

We can set a commit status that will show red if the user hasn’t signed the CLA (just like if Travis tests failed or so). No need to use a banner or anything. This is a great idea. Almost any automated check we want to run against PRs can be captured as a Travis/CI test that shows up on the PR wit

Re: [core-workflow] Standard library separation from core (was Re: My initial thoughts on the steps/blockers of the transition)

, lets you use the Python 3 import system in Python 2). So is the intention that, over the long term, these PyPI counterparts would cannibalize their standard library equivalents in terms of usage? Nick ​ On Mon, Jan 4, 2016 at 10:38 PM Nick Coghlan wrote: > On 5 January 2016 at 12:50, Nicho

Re: [core-workflow] My initial thoughts on the steps/blockers of the transition

Something else to consider. We’ve long talked about splitting out the stdlib to make it easier for the alternative implementations to import. If some or all of them also switch to git, we could do that pretty easily with git submodules. Not to derail here, but wasn’t there a discussion (perhaps on

Re: [core-workflow] We will be moving to GitHub

On Sat, Jan 2, 2016 at 10:41 PM Barry Warsaw ba...@python.org wrote: It heartening to know that we all care enough about Python, past, present, and future to want to see it succeed not just technically, but socially as well, and decisions about where and how our co

Re: [core-workflow] We will be moving to GitHub

First-timer here on this list. Just wanted to chime in briefly on a few things. Basically a way to map an issue to a PR (or vice-versa). Probably the simplest solution is to allow pasting in a GitHub PR URL or the PR # to make the association. The other option is for the bot to accept a command to