From senthil at uthcode.com Fri Jul 8 21:30:29 2016 From: senthil at uthcode.com (Senthil Kumaran) Date: Fri, 8 Jul 2016 18:30:29 -0700 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration Message-ID: I noticed two issues wherein the reporters were confused with the github mirrors of cpython. 1. http://bugs.python.org/issue25435#msg253159 A pull request was raised against the github mirror. 2. http://bugs.python.org/issue27466 Issue was raised against a github mirror: https://github.com/python-git/python/issues/6 This project, https://github.com/python-git should either redirect to github.com/python or shutdown. And the github.com/python project should disallow Pull Request / Issue Creation. Who can I work with (in the python infra team) to accomplish these things? Also if anyone else has suggestions please share it in this email thread. Thank you, Senthil -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas.chammas at gmail.com Fri Jul 8 21:35:07 2016 From: nicholas.chammas at gmail.com (Nicholas Chammas) Date: Sat, 09 Jul 2016 01:35:07 +0000 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References: Message-ID: I know you can disable issues for a repo on GitHub, but I don't think you can disable PRs, unfortunately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Fri Jul 8 21:50:40 2016 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Fri, 8 Jul 2016 18:50:40 -0700 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References: Message-ID: > > Who can I work with (in the python infra team) to accomplish these things? > Also if anyone else has suggestions please share it in this email thread. > You might be able to nicely ask GitHub support. There are some github feature that can be activated only by them for some good reasons, for example detaching a fork. If it's still not possible, the-knights-who-says-ni[1] could help with auto responding/closing. -- M [1]: https://github.com/python/the-knights-who-say-ni From brett at python.org Sat Jul 9 11:59:04 2016 From: brett at python.org (Brett Cannon) Date: Sat, 09 Jul 2016 15:59:04 +0000 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References: Message-ID: The problem with the python-tutor org is we don't control it and we don't know whose it is. As for turning off the PRs for Python/cpython, GH doesn't provide a way to do that. Best we can do is reply to the PRs to say the repo is just a mirror and PRs are not accepted and get the transition done sooner rather than later (hoping to get the devguide moved this month; need to schedule it with the PDF infra team). On Fri, Jul 8, 2016, 18:30 Senthil Kumaran wrote: > I noticed two issues wherein the reporters were confused with the > github mirrors of cpython. > > 1. http://bugs.python.org/issue25435#msg253159 > > A pull request was raised against the github mirror. > > 2. http://bugs.python.org/issue27466 > > Issue was raised against a github mirror: > https://github.com/python-git/python/issues/6 > > This project, https://github.com/python-git should either redirect to > github.com/python or shutdown. > And the github.com/python project should disallow Pull Request / Issue > Creation. > > Who can I work with (in the python infra team) to accomplish these things? > Also if anyone else has suggestions please share it in this email thread. > > Thank you, > Senthil > > _______________________________________________ > 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: From phd at phdru.name Sat Jul 9 12:06:23 2016 From: phd at phdru.name (Oleg Broytman) Date: Sat, 9 Jul 2016 18:06:23 +0200 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References: Message-ID: <20160709160623.GA16012@phdru.name> python-tutor => python-git (-: On Sat, Jul 09, 2016 at 03:59:04PM +0000, Brett Cannon wrote: > The problem with the python-tutor org is we don't control it and we don't > know whose it is. > > > > Issue was raised against a github mirror: > > https://github.com/python-git/python/issues/6 > > > > This project, https://github.com/python-git should either redirect to > > github.com/python or shutdown. Oleg. -- Oleg Broytman http://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From willingc at willingconsulting.com Sat Jul 9 15:55:12 2016 From: willingc at willingconsulting.com (Carol Willing) Date: Sat, 09 Jul 2016 19:55:12 +0000 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References: Message-ID: Hi Brett, One thing that could be done is to use a pull request template to notify users BEFORE they make a PR that the CPython mirror is not the correct place to submit contributions. See https://github.com/python/cpython/pull/41 as an example of the template. Carol \--- Carol Willing Research Software Engineer Project Jupyter @ Cal Poly SLO Director, Python Software Foundation _Signature strengths_ _Empathy - Relator - Ideation - Strategic - Learner_ ![](https://link.nylas.com/open/1oeantoc6n5zav9mkp4e6rmlq/local-67d93f1d- ff23?r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) On Jul 9 2016, at 8:59 am, Brett Cannon <brett at python.org> wrote: > The problem with the python-tutor org is we don't control it and we don't know whose it is. > > > > > As for turning off the PRs for Python/cpython, GH doesn't provide a way to do that. Best we can do is reply to the PRs to say the repo is just a mirror and PRs are not accepted and get the transition done sooner rather than later (hoping to get the devguide moved this month; need to schedule it with the PDF infra team). > > > > On Fri, Jul 8, 2016, 18:30 Senthil Kumaran <[senthil at uthcode.com](mailto:senthil at uthcode.com)> wrote: > > >> I noticed two issues wherein the reporters were confused with the github mirrors of cpython. >> >> > >> >> 1. [http://bugs.python.org/issue25435#msg253159](http://bugs.python.org/issue25435#msg253159&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) >> >> > >> >> A pull request was raised against the github mirror. >> >> > >> >> 2. [http://bugs.python.org/issue27466](http://bugs.python.org/issue27466&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) >> >> > >> >> Issue was raised against a github mirror: [https://github.com/python- git/python/issues/6](https://github.com/python- git/python/issues/6&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) >> >> > >> >> This project, [https://github.com/python-git](https://github.com/python- git&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) should either redirect to [github.com/python](http://github.com/python&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) or shutdown. >> >> And the [github.com/python](http://github.com/python&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) project should disallow Pull Request / Issue Creation. >> >> > >> >> Who can I work with (in the python infra team) to accomplish these things? Also if anyone else has suggestions please share it in this email thread. >> >> > >> >> Thank you, >> >> Senthil >> >> > >> >> _______________________________________________ > core-workflow mailing list > [core-workflow at python.org](mailto:core-workflow at python.org) > [https://mail.python.org/mailman/listinfo/core- workflow](https://mail.python.org/mailman/listinfo/core- workflow&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) > This list is governed by the PSF Code of Conduct: [https://www.python.org/psf/codeofconduct](https://www.python.org/psf/codeofconduct&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sat Jul 9 21:12:36 2016 From: brett at python.org (Brett Cannon) Date: Sun, 10 Jul 2016 01:12:36 +0000 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References:

Message-ID: On Sat, 9 Jul 2016 at 13:01 Carol Willing wrote: > Hi Brett, > > One thing that could be done is to use a pull request template to notify > users BEFORE they make a PR that the CPython mirror is not the correct > place to submit contributions. > > See https://github.com/python/cpython/pull/41 as an example of the > template. > The problem with a template is it has to be checked into the cpython repository which will make sense once we migrate, but I don't know if it does while we are not moved over yet. -Brett > > Carol > > --- > Carol Willing > > Research Software Engineer > Project Jupyter @ Cal Poly SLO > > Director, Python Software Foundation > > *Signature strengths* > *Empathy - Relator - Ideation - Strategic - Learner* > > On Jul 9 2016, at 8:59 am, Brett Cannon wrote: > >> The problem with the python-tutor org is we don't control it and we don't >> know whose it is. >> >> As for turning off the PRs for Python/cpython, GH doesn't provide a way >> to do that. Best we can do is reply to the PRs to say the repo is just a >> mirror and PRs are not accepted and get the transition done sooner rather >> than later (hoping to get the devguide moved this month; need to schedule >> it with the PDF infra team). >> >> On Fri, Jul 8, 2016, 18:30 Senthil Kumaran wrote: >> >> I noticed two issues wherein the reporters were confused with the >> github mirrors of cpython. >> >> 1. http://bugs.python.org/issue25435#msg253159 >> >> >> A pull request was raised against the github mirror. >> >> 2. http://bugs.python.org/issue27466 >> >> >> Issue was raised against a github mirror: >> https://github.com/python-git/python/issues/6 >> >> >> This project, https://github.com/python-git >> should >> either redirect to github.com/python >> or shutdown. >> And the github.com/python >> project should >> disallow Pull Request / Issue Creation. >> >> Who can I work with (in the python infra team) to accomplish these >> things? Also if anyone else has suggestions please share it in this email >> thread. >> >> Thank you, >> Senthil >> >> _______________________________________________ >> 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: From willingc at willingconsulting.com Sat Jul 9 22:12:23 2016 From: willingc at willingconsulting.com (Carol Willing) Date: Sun, 10 Jul 2016 02:12:23 +0000 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References:

Message-ID: ![](https://link.nylas.com/open/1oeantoc6n5zav9mkp4e6rmlq/local-bcd5514a- 5c6f?r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) On Jul 9 2016, at 6:12 pm, Brett Cannon <brett at python.org> wrote: > > > > > > > On Sat, 9 Jul 2016 at 13:01 Carol Willing <[willingc at willingconsulting.com](mailto:willingc at willingconsulting.com)> wrote: > > >> Hi Brett, >> >> > >> >> One thing that could be done is to use a pull request template to notify users BEFORE they make a PR that the CPython mirror is not the correct place to submit contributions. >> >> > >> >> See [https://github.com/python/cpython/pull/41](https://github.com/python/cpython/pull/41&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) as an example of the template. > > > > > The problem with a template is it has to be checked into the cpython repository which will make sense once we migrate, but I don't know if it does while we are not moved over yet. > > > I was thinking that you could check-in to the GitHub mirror in a .git directory unless mirroring would blow it away each update. I wasn't thinking it would need to be in the hg hosting of CPython code. Removing it once the migration happens. > > > > > > > -Brett > > > >> > >> >> Carol >> >> > \--- >> >> Carol Willing >> >> > >> >> Research Software Engineer >> >> Project Jupyter @ Cal Poly SLO >> >> > >> >> Director, Python Software Foundation >> >> > >> >> _Signature strengths_ >> >> _Empathy - Relator - Ideation - Strategic - Learner_ >> >> > >> >> On Jul 9 2016, at 8:59 am, Brett Cannon <[brett at python.org](mailto:brett at python.org)> wrote: > >> >>> The problem with the python-tutor org is we don't control it and we don't know whose it is. >>> >>> > >>> >>> As for turning off the PRs for Python/cpython, GH doesn't provide a way to do that. Best we can do is reply to the PRs to say the repo is just a mirror and PRs are not accepted and get the transition done sooner rather than later (hoping to get the devguide moved this month; need to schedule it with the PDF infra team). > > >>> >>> On Fri, Jul 8, 2016, 18:30 Senthil Kumaran <[senthil at uthcode.com](mailto:senthil at uthcode.com)> wrote: > >>> >>>> I noticed two issues wherein the reporters were confused with the github mirrors of cpython. >>>> >>>> > >>>> >>>> 1. [http://bugs.python.org/issue25435#msg253159](http://bugs.python.org/issue25435#msg253159&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) >>>> >>>> > >>>> >>>> A pull request was raised against the github mirror. >>>> >>>> > >>>> >>>> 2. [http://bugs.python.org/issue27466](http://bugs.python.org/issue27466&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) >>>> >>>> > >>>> >>>> Issue was raised against a github mirror: [https://github.com/python- git/python/issues/6](https://github.com/python- git/python/issues/6&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) >>>> >>>> > >>>> >>>> This project, [https://github.com/python-git](https://github.com/python- git&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) should either redirect to [github.com/python](http://github.com/python&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) or shutdown. >>>> >>>> And the [github.com/python](http://github.com/python&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) project should disallow Pull Request / Issue Creation. >>>> >>>> > >>>> >>>> Who can I work with (in the python infra team) to accomplish these things? Also if anyone else has suggestions please share it in this email thread. >>>> >>>> > >>>> >>>> Thank you, >>>> >>>> Senthil >>>> >>>> > >>>> >>>> _______________________________________________ > core-workflow mailing list > [core-workflow at python.org](mailto:core-workflow at python.org) > [https://mail.python.org/mailman/listinfo/core- workflow](https://mail.python.org/mailman/listinfo/core- workflow&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) > This list is governed by the PSF Code of Conduct: [https://www.python.org/psf/codeofconduct](https://www.python.org/psf/codeofconduct&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Sun Jul 10 03:15:02 2016 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 10 Jul 2016 17:15:02 +1000 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References:

Message-ID: On 10 July 2016 at 11:12, Brett Cannon wrote: > > > On Sat, 9 Jul 2016 at 13:01 Carol Willing > wrote: > >> Hi Brett, >> >> One thing that could be done is to use a pull request template to notify >> users BEFORE they make a PR that the CPython mirror is not the correct >> place to submit contributions. >> >> See https://github.com/python/cpython/pull/41 as an example of the >> template. >> > > The problem with a template is it has to be checked into the cpython > repository which will make sense once we migrate, but I don't know if it > does while we are not moved over yet. > I don't see any problem with doing that early - we already carry a .gitignore file for the benefit of folks using hg-git bridges, so if we wanted to start experimenting with GitHub workflows (including things like Travis CI), why gate that on actually doing the migration first if we can use the existing mirrors for it? Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Sun Jul 10 09:33:38 2016 From: senthil at uthcode.com (Senthil Kumaran) Date: Sun, 10 Jul 2016 06:33:38 -0700 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References:

Message-ID: On Sun, Jul 10, 2016 at 12:15 AM, Nick Coghlan wrote: > > I don't see any problem with doing that early - we already carry a .gitignore file for the benefit of folks using hg-git bridges, so if we wanted to start experimenting with GitHub workflows (including things like Travis CI), why gate that on actually doing the migration first if we can use the existing mirrors for it? I am in favor of introducing this before the migration. It seems like an easy thing to setup without any clutter to the existing setup. For e.g, for the pull request template, We can have the PULL_REQUEST_TEMPLATE.md as suggested by Carol inside a .github directory in hg repo and communicate our intention. That should address one of the points in this thread. Thanks, Senthil From berker.peksag at gmail.com Sun Jul 10 10:19:49 2016 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Sun, 10 Jul 2016 17:19:49 +0300 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References:

Message-ID: On Sun, Jul 10, 2016 at 4:33 PM, Senthil Kumaran wrote: > On Sun, Jul 10, 2016 at 12:15 AM, Nick Coghlan wrote: >> >> I don't see any problem with doing that early - we already carry a .gitignore file for the benefit of folks using hg-git bridges, so if we wanted to start experimenting with GitHub workflows (including things like Travis CI), why gate that on actually doing the migration first if we can use the existing mirrors for it? > > > I am in favor of introducing this before the migration. It seems like > an easy thing to setup without any clutter to the existing setup. > For e.g, for the pull request template, We can have the > PULL_REQUEST_TEMPLATE.md as suggested by Carol inside a .github > directory in hg repo and communicate our intention. That should > address one of the points in this thread. I'm not sure how that would solve the main problem: People do not like to read project descriptions and contribution guides :) python/cpython description already states that it's a read-only mirror of the Mercurial repository and it took me a second to realize that python-git/python is a way outdated mirror of the old SVN repository. I'd propose to set a webhook that will close all pull requests automatically (with a short informative message) on python/cpython. I'm planning to finish my merge bot this month so I can write a simple webhook quickly if needed. --Berker From willingc at willingconsulting.com Sun Jul 10 11:05:57 2016 From: willingc at willingconsulting.com (Carol Willing) Date: Sun, 10 Jul 2016 15:05:57 +0000 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References:

Message-ID: <6ic72y6kkum7ldjfd8h9gtqma-2147483647@mailer.nylas.com> ![](https://link.nylas.com/open/1oeantoc6n5zav9mkp4e6rmlq/local- 896ba456-d22b?r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) On Jul 10 2016, at 7:20 am, Berker Peksa? <berker.peksag at gmail.com> wrote: > On Sun, Jul 10, 2016 at 4:33 PM, Senthil Kumaran <senthil at uthcode.com> wrote: > > On Sun, Jul 10, 2016 at 12:15 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: > >> > >> I don't see any problem with doing that early - we already carry a .gitignore file for the benefit of folks using hg-git bridges, so if we wanted to start experimenting with GitHub workflows (including things like Travis CI), why gate that on actually doing the migration first if we can use the existing mirrors for it? > > > > > > I am in favor of introducing this before the migration. It seems like > > an easy thing to setup without any clutter to the existing setup. > > For e.g, for the pull request template, We can have the > > PULL_REQUEST_TEMPLATE.md as suggested by Carol inside a .github > > directory in hg repo and communicate our intention. That should > > address one of the points in this thread. > > I'm not sure how that would solve the main problem: People do not like > to read project descriptions and contribution guides :) The template is a simple courtesy to alert those opening a PR on the repo that it's not the right place. Of course, people might still not read it ;-) > > > > python/cpython > description already states that it's a read-only mirror of the > Mercurial repository and it took me a second to realize that > python-git/python is a way outdated mirror of the old SVN repository. > > I'd propose to set a webhook that will close all pull requests > automatically (with a short informative message) on python/cpython. > I'm planning to finish my merge bot this month so I can write a simple > webhook quickly if needed. Sure, that's helpful for the maintainers too. The template saves a potential contributor the embarassment/frustration of opening a PR just to have it closed moments later. > > > > \--Berker > > _______________________________________________ > 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: From brett at python.org Sun Jul 10 12:33:39 2016 From: brett at python.org (Brett Cannon) Date: Sun, 10 Jul 2016 16:33:39 +0000 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References:

Message-ID: On Sun, 10 Jul 2016 at 00:15 Nick Coghlan wrote: > On 10 July 2016 at 11:12, Brett Cannon wrote: > >> >> >> On Sat, 9 Jul 2016 at 13:01 Carol Willing >> wrote: >> >>> Hi Brett, >>> >>> One thing that could be done is to use a pull request template to notify >>> users BEFORE they make a PR that the CPython mirror is not the correct >>> place to submit contributions. >>> >>> See https://github.com/python/cpython/pull/41 as an example of the >>> template. >>> >> >> The problem with a template is it has to be checked into the cpython >> repository which will make sense once we migrate, but I don't know if it >> does while we are not moved over yet. >> > > I don't see any problem with doing that early - we already carry a > .gitignore file for the benefit of folks using hg-git bridges, so if we > wanted to start experimenting with GitHub workflows (including things like > Travis CI), why gate that on actually doing the migration first if we can > use the existing mirrors for it? > OK, then feel free to commit it to hg.python.org/cpython (I doubt it can be committed to the git repo since the mirroring either does a push which will fail do to the difference or it does a `push --force` which will just overwrite the change). I'm personally busy with other stuff right now and this is low-priority for me personally as we get at most two accidental PRs a month ATM so I'm going to pass on putting this ahead of other stuff I need to get done for 3.6 or the devguide (this isn't meant to sound frustrated or anything, BTW). -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Sun Jul 10 15:02:13 2016 From: senthil at uthcode.com (Senthil Kumaran) Date: Sun, 10 Jul 2016 12:02:13 -0700 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References:

Message-ID: On Sun, Jul 10, 2016 at 9:33 AM, Brett Cannon wrote: > OK, then feel free to commit it to hg.python.org/cpython Let's try this one. I adopted Carol's patch to here: http://bugs.python.org/issue27476 If someone reviews this, I will go ahead with pushing this and see if this helps. Thanks, Senthil From brett at python.org Mon Jul 11 14:09:58 2016 From: brett at python.org (Brett Cannon) Date: Mon, 11 Jul 2016 18:09:58 +0000 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References:

Message-ID: Senthil pushed Carol's PR template. I just went through and quickly closed all the open PRs w/ the same message saying thanks for the PR, but please use bugs.python.org. On Sun, 10 Jul 2016 at 12:02 Senthil Kumaran wrote: > On Sun, Jul 10, 2016 at 9:33 AM, Brett Cannon wrote: > > > OK, then feel free to commit it to hg.python.org/cpython > > Let's try this one. I adopted Carol's patch to here: > http://bugs.python.org/issue27476 > If someone reviews this, I will go ahead with pushing this and see if > this helps. > > Thanks, > Senthil > _______________________________________________ > 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: From willingc at willingconsulting.com Mon Jul 11 16:30:14 2016 From: willingc at willingconsulting.com (Carol Willing) Date: Mon, 11 Jul 2016 20:30:14 +0000 Subject: [core-workflow] Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration In-Reply-To: References:

Message-ID: Thanks Senthil and Brett. \--- Carol Willing Research Software Engineer Project Jupyter @ Cal Poly SLO Director, Python Software Foundation _Signature strengths_ _Empathy - Relator - Ideation - Strategic - Learner_ ![](https://link.nylas.com/open/1oeantoc6n5zav9mkp4e6rmlq/local- d58baf84-ad3b?r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) On Jul 11 2016, at 1:10 pm, Brett Cannon <brett at python.org> wrote: > Senthil pushed Carol's PR template. I just went through and quickly closed all the open PRs w/ the same message saying thanks for the PR, but please use [bugs.python.org](http://bugs.python.org&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn). > > > > > On Sun, 10 Jul 2016 at 12:02 Senthil Kumaran <[senthil at uthcode.com](mailto:senthil at uthcode.com)> wrote: > > >> On Sun, Jul 10, 2016 at 9:33 AM, Brett Cannon <[brett at python.org](mailto:brett at python.org)> wrote: > > > OK, then feel free to commit it to [hg.python.org/cpython](http://hg.python.org/cpython&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) > > Let's try this one. I adopted Carol's patch to here: > [http://bugs.python.org/issue27476](http://bugs.python.org/issue27476&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) > If someone reviews this, I will go ahead with pushing this and see if > this helps. > > Thanks, > Senthil > _______________________________________________ > core-workflow mailing list > [core-workflow at python.org](mailto:core-workflow at python.org) > [https://mail.python.org/mailman/listinfo/core- workflow](https://mail.python.org/mailman/listinfo/core- workflow&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) > This list is governed by the PSF Code of Conduct: [https://www.python.org/psf/codeofconduct](https://www.python.org/psf/codeofconduct&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sat Jul 16 20:46:48 2016 From: brett at python.org (Brett Cannon) Date: Sun, 17 Jul 2016 00:46:48 +0000 Subject: [core-workflow] What would it take to split the stdlib out into its own git repo? Message-ID: What would be involved in making the stdlib its own repo, separate from CPython itself? Now I'm not suggesting making sure it fully functions on its own, but more of what would need to happen if we decided that the stdlib should be its own git repo so that any Python implementation -- including CPython -- would include the stdlib as e.g. a git submodule? For instance, would we be able to split the history, or would the original history stay in the CPython repo and we would start from scratch in the stdlib repo and `git log` would hopefully be smart enough to merge the two histories? How bad is it to work in a repo with a submodule where you will be making changes to submodules regularly? And are there benefits? My hope/hunch is that if we make the stdlib its own repo then other implementations could include the stdlib as a submodule or something, making it easier for them to not only keep up-to-date with fixes to the stdlib, but also make it easier for them to push changes upstream that everyone would benefit from instead of having any changes silo-ed off in their own repo. Am I nuts, or is this something reasonable to consider doing as part of the GitHub migration? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Sat Jul 16 20:54:01 2016 From: rosuav at gmail.com (Chris Angelico) Date: Sun, 17 Jul 2016 10:54:01 +1000 Subject: [core-workflow] What would it take to split the stdlib out into its own git repo? In-Reply-To: References: Message-ID: On Sun, Jul 17, 2016 at 10:46 AM, Brett Cannon wrote: > For instance, would we be able to split the history, or would the original > history stay in the CPython repo and we would start from scratch in the > stdlib repo and `git log` would hopefully be smart enough to merge the two > histories? How bad is it to work in a repo with a submodule where you will > be making changes to submodules regularly? I detest working with git submodules; if the repositories get split, I'd much rather have ./python look for ../python-stdlib as a parallel repo. They stand entirely separately; you simply clone both repos into the same directory. (For example, the editor SciTE and its component Scintilla work this way. I have /home/rosuav/scintilla and /home/rosuav/scite, and build Scintilla first, then build SciTE. The building part wouldn't be an issue with the stdlib, so it'd be easier.) Splitting out the history can certainly be done. You simply clone the main CPython git repo, then tell git to throw away everything that isn't in the Lib/ directory. Not all commits will read sensibly like that (maybe there's a trivial edit to the stdlib, associated with a core interpreter edit, and the commit message mentions only the core), but it's faithful and reliable, and you get the full history, going back deep into the Mercurial days. (And earlier, if the hg repo imported other data.) ChrisA From donald at stufft.io Sat Jul 16 20:55:01 2016 From: donald at stufft.io (Donald Stufft) Date: Sat, 16 Jul 2016 20:55:01 -0400 Subject: [core-workflow] What would it take to split the stdlib out into its own git repo? In-Reply-To: References: Message-ID: > On Jul 16, 2016, at 8:46 PM, Brett Cannon wrote: > > What would be involved in making the stdlib its own repo, separate from CPython itself? Now I'm not suggesting making sure it fully functions on its own, but more of what would need to happen if we decided that the stdlib should be its own git repo so that any Python implementation -- including CPython -- would include the stdlib as e.g. a git submodule? For instance, would we be able to split the history, or would the original history stay in the CPython repo and we would start from scratch in the stdlib repo and `git log` would hopefully be smart enough to merge the two histories? How bad is it to work in a repo with a submodule where you will be making changes to submodules regularly? It?s kind of miserable in my experience TBH. > > And are there benefits? My hope/hunch is that if we make the stdlib its own repo then other implementations could include the stdlib as a submodule or something, making it easier for them to not only keep up-to-date with fixes to the stdlib, but also make it easier for them to push changes upstream that everyone would benefit from instead of having any changes silo-ed off in their own repo. The C-extensions part might be hard for this, since that?s an implementation detail of CPython. This is probably best asked of PyPy, Python, etc though. One thing though, you don?t need to split out into a separate repo to allow people to do this, they can do git sub-tree merges from CPython into their own git repos (https://jrsmith3.github.io/merging-a-subdirectory-from-another-repo-via-git-subtree.html ). > > Am I nuts, or is this something reasonable to consider doing as part of the GitHub migration? I?m not sure I see a whole lot of value here unless we make it possible to release the stdlib separately tbh. > _______________________________________________ > 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 ? Donald Stufft -------------- next part -------------- An HTML attachment was scrubbed... URL: From rymg19 at gmail.com Sat Jul 16 20:59:59 2016 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Sat, 16 Jul 2016 19:59:59 -0500 Subject: [core-workflow] What would it take to split the stdlib out into its own git repo? In-Reply-To: References: Message-ID: On Jul 16, 2016 7:54 PM, "Chris Angelico" wrote: > > On Sun, Jul 17, 2016 at 10:46 AM, Brett Cannon wrote: > > For instance, would we be able to split the history, or would the original > > history stay in the CPython repo and we would start from scratch in the > > stdlib repo and `git log` would hopefully be smart enough to merge the two > > histories? How bad is it to work in a repo with a submodule where you will > > be making changes to submodules regularly? > > I detest working with git submodules; if the repositories get split, > I'd much rather have ./python look for ../python-stdlib as a parallel > repo. They stand entirely separately; you simply clone both repos into > the same directory. (For example, the editor SciTE and its component > Scintilla work this way. I have /home/rosuav/scintilla and > /home/rosuav/scite, and build Scintilla first, then build SciTE. The > building part wouldn't be an issue with the stdlib, so it'd be > easier.) What about subtrees: https://medium.com/@porteneuve/mastering-git-subtrees-943d29a798ec#.6bbjxspcj > > Splitting out the history can certainly be done. You simply clone the > main CPython git repo, then tell git to throw away everything that > isn't in the Lib/ directory. Not all commits will read sensibly like > that (maybe there's a trivial edit to the stdlib, associated with a > core interpreter edit, and the commit message mentions only the core), > but it's faithful and reliable, and you get the full history, going > back deep into the Mercurial days. (And earlier, if the hg repo > imported other data.) > > ChrisA > _______________________________________________ > 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 -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something?s wrong. http://kirbyfan64.github.io/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Sat Jul 16 20:59:57 2016 From: rosuav at gmail.com (Chris Angelico) Date: Sun, 17 Jul 2016 10:59:57 +1000 Subject: [core-workflow] What would it take to split the stdlib out into its own git repo? In-Reply-To: References: Message-ID: On Sun, Jul 17, 2016 at 10:54 AM, Chris Angelico wrote: > if the repositories get split, > I'd much rather have ./python look for ../python-stdlib as a parallel > repo. They stand entirely separately; you simply clone both repos into > the same directory. Oh, and if you tell people to do it this way, you can "ln -s ../python-stdlib Lib" and commit that symlink into the repo. Existing code needn't even be changed. When you clone a repo that has submodules, you have to know to run another command to update the submodules. Likewise when you pull changes. Same diff as having two stand-alone repos. Splitting the stdlib is going to make things a little harder no matter how it's done, so it wants to be worthwhile. ChrisA From rosuav at gmail.com Sat Jul 16 21:05:05 2016 From: rosuav at gmail.com (Chris Angelico) Date: Sun, 17 Jul 2016 11:05:05 +1000 Subject: [core-workflow] What would it take to split the stdlib out into its own git repo? In-Reply-To: References:

Message-ID: On Sun, Jul 17, 2016 at 10:59 AM, Ryan Gonzalez wrote: >> I detest working with git submodules; if the repositories get split, >> I'd much rather have ./python look for ../python-stdlib as a parallel >> repo. They stand entirely separately; you simply clone both repos into >> the same directory. (For example, the editor SciTE and its component >> Scintilla work this way. I have /home/rosuav/scintilla and >> /home/rosuav/scite, and build Scintilla first, then build SciTE. The >> building part wouldn't be an issue with the stdlib, so it'd be >> easier.) > > What about subtrees: > > https://medium.com/@porteneuve/mastering-git-subtrees-943d29a798ec#.6bbjxspcj Never used them; from a look at the article, that would include the whole stdlib history still in the main repo, right? I'm not sure how well this would scale to lots of people with lots of repos, or how you'd clone appropriately. There would be duplicate commits (one in stdlib, one in main) with different hashes, or else a really messy graph of merges. Not sure this is an improvement. ChrisA From phd at phdru.name Sat Jul 16 21:01:38 2016 From: phd at phdru.name (Oleg Broytman) Date: Sun, 17 Jul 2016 03:01:38 +0200 Subject: [core-workflow] What would it take to split the stdlib out into its own git repo? In-Reply-To: References:

Message-ID: <20160717010138.GA21216@phdru.name> On Sun, Jul 17, 2016 at 10:59:57AM +1000, Chris Angelico wrote: > Oh, and if you tell people to do it this way, you can "ln -s > ../python-stdlib Lib" and commit that symlink into the repo. Doesn't work on w32 AFAIK. Oleg. -- Oleg Broytman http://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From nad at python.org Sat Jul 16 21:27:41 2016 From: nad at python.org (Ned Deily) Date: Sat, 16 Jul 2016 21:27:41 -0400 Subject: [core-workflow] What would it take to split the stdlib out into its own git repo? In-Reply-To: References: Message-ID: On Jul 16, 2016, at 20:46, Brett Cannon wrote: > And are there benefits? My hope/hunch is that if we make the stdlib its own repo then other implementations could include the stdlib as a submodule or something, making it easier for them to not only keep up-to-date with fixes to the stdlib, but also make it easier for them to push changes upstream that everyone would benefit from instead of having any changes silo-ed off in their own repo. Without giving it a lot of thought, this strikes me as an unnecessary complication. It will undoubtedly make CPython development more complicated, both initially in separating the stdlib out and, in the long run, figuring out how to keep them in sync all the time. Other Python implementations already have to deal with this, if they want to, and they can very easily ignore the CPython-specific parts of the repo without having to add all this additional work on everyone. Let's not make this migration harder than it has to be. We've got enough to do already. -- Ned Deily nad at python.org -- [] From guido at python.org Sat Jul 16 21:41:42 2016 From: guido at python.org (Guido van Rossum) Date: Sat, 16 Jul 2016 18:41:42 -0700 Subject: [core-workflow] What would it take to split the stdlib out into its own git repo? In-Reply-To: References:

Message-ID: I think Ned strikes the nail on the head. It's a fair burden to keep the repos in sync. I propose that instead we have some script that can make a release of just the stdlib for the benefits of other Python implementations. FWIW I've got a fair bit of experience using a subrepo for a similar purpose, using the proposed separation: mypy depends on typeshed and includes it as a subrepo; but there are other users of typeshed as well (Google's pytype, as well as PyCharm). I think it's nice that the mypy history and the typeshed history are separate. Keeping typeshed up to date when you switch mypy branches is easy enough using a git hook. The two places where it breaks down: First, there's an endless series of "sync typeshed" commits to the mypy repo. We do these frequently because we have users of mypy (e.g. Dropbox) who sync with the development head of mypy regularly --much more often than mypy releases go out-- and who often want improvements to typeshed as well as improvements to mypy. When using mypy we don't point it to a separate copy of typeshed --it would too often be out of sync-- instead we install from mypy's master branch which also syncs to a recent version of typeshed. Second, tests. Mypy's tests depend on typeshed, and typeshed's tests depend on mypy. It's a never-ending nightmare (or rather, death by a thousand cuts). In the mypy world we live with this because we really want to encourage shared ownership of typeshed (and Google's pytype team reviews and merges a significant number of typeshed PRs and sometimes brings up concerns when we forget that typeshed doesn't exist just to support mypy). But for Python I think the situation is just asymmetric, and separating out the stdlib isn't going to suddenly level the playing field. So the burden for the core Python devs is not warranted, IMO. --Guido From guido at python.org Sat Jul 16 21:53:38 2016 From: guido at python.org (Guido van Rossum) Date: Sat, 16 Jul 2016 18:53:38 -0700 Subject: [core-workflow] What would it take to split the stdlib out into its own git repo? In-Reply-To: <20160717010138.GA21216@phdru.name> References:

<20160717010138.GA21216@phdru.name> Message-ID: More importantly, you'd get into lots of situations where the heads of the two trees don't work together. And separate versioning is just not realistic for the stdlib. On Saturday, July 16, 2016, Oleg Broytman wrote: > On Sun, Jul 17, 2016 at 10:59:57AM +1000, Chris Angelico > wrote: > > Oh, and if you tell people to do it this way, you can "ln -s > > ../python-stdlib Lib" and commit that symlink into the repo. > > Doesn't work on w32 AFAIK. > > Oleg. > -- > Oleg Broytman http://phdru.name/ phd at phdru.name > > Programmers don't die, they just GOSUB without RETURN. > _______________________________________________ > 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 > -- --Guido (mobile) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Sun Jul 17 06:50:53 2016 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 17 Jul 2016 20:50:53 +1000 Subject: [core-workflow] What would it take to split the stdlib out into its own git repo? In-Reply-To: References:

Message-ID: On 17 July 2016 at 11:27, Ned Deily wrote: > On Jul 16, 2016, at 20:46, Brett Cannon wrote: >> And are there benefits? My hope/hunch is that if we make the stdlib its own repo then other implementations could include the stdlib as a submodule or something, making it easier for them to not only keep up-to-date with fixes to the stdlib, but also make it easier for them to push changes upstream that everyone would benefit from instead of having any changes silo-ed off in their own repo. > > Without giving it a lot of thought, this strikes me as an unnecessary complication. It will undoubtedly make CPython development more complicated, both initially in separating the stdlib out and, in the long run, figuring out how to keep them in sync all the time. Other Python implementations already have to deal with this, if they want to, and they can very easily ignore the CPython-specific parts of the repo without having to add all this additional work on everyone. Let's not make this migration harder than it has to be. We've got enough to do already. +1. Aside from the practical problems with the git separation itself, we also have the problem of getpath.c already being a tremendously complicated piece of imperative logic (combining both compile time and runtime checks, with an entirely separate implementation for Windows), which would need updating to cope with separation of the standard library into "the cross-implementation bits" and "the CPython bits". That said, I'd actually be in favour of doing such a structural split *within* the repo (similar to the way we separated out the Programs directory a while back), but even that would be quite a lot of tedious work for minimal real gain. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From brett at python.org Fri Jul 22 17:59:39 2016 From: brett at python.org (Brett Cannon) Date: Fri, 22 Jul 2016 21:59:39 +0000 Subject: [core-workflow] Devguide migrated and next steps Message-ID: The devguide is now at https://github.com/python/devguide! Since I'm not waiting on the benchmarks repo while Victor Stinner does some perf measuring work, that means the cpython repo is next . If you look at https://www.python.org/dev/peps/pep-0512/#status you will see the list of issues that have to occur in order to migrate the cpython repo: 1. Update the devguide to document how we want to use git and GitHub ( https://github.com/python/devguide/milestone/1) 2. Link a PR to an issue (see http://psf.upfronthosting.co.za/roundup/meta/issue589) 3. Update an issue when a PR is closed (I believe http://psf.upfronthosting.co.za/roundup/meta/issue590 covers this) 4. Update hg.python.org/lookup to work with git hashes 5. Deprecate sys._mercurial and create sys._git ( http://bugs.python.org/issue27593) 6. Update PEP 101 Obviously help with any and all of this is appreciated and if you feel anything needs discussion then please start a new thread on the topic (and don't simply reply to this email so we can keep discussions separate). -------------- next part -------------- An HTML attachment was scrubbed... URL: From shah.anish07 at gmail.com Wed Jul 27 16:00:09 2016 From: shah.anish07 at gmail.com (Anish Shah) Date: Thu, 28 Jul 2016 01:30:09 +0530 Subject: [core-workflow] GitHub reviews comments on b.p.o Message-ID: Hello everyone, I'm working on GitHub integration as a part of GSoC. One of my tasks was to show GitHub review comments on b.p.o. Here is how I did it :- I wrote a handler to handle GitHub PR review/diff comments event using webhooks. If a b.p.o issue is linked to a PR, then it checks if any "GitHub" comment was added in last "X" minutes. If no GitHub comments were added, then it adds that comment to the linked issue. This way there will be fewer emails and also developers who are in the nosy list but are not subscribed to GitHub PR will get notified about the progress/review comments on PR. You can check the patch here . I wanted to know from you all if this is the right approach. If not, then what should be changed? Thank you, Anish Shah -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Wed Jul 27 17:00:09 2016 From: senthil at uthcode.com (Senthil Kumaran) Date: Wed, 27 Jul 2016 14:00:09 -0700 Subject: [core-workflow] GitHub reviews comments on b.p.o In-Reply-To: References: Message-ID: On Wed, Jul 27, 2016 at 1:00 PM, Anish Shah wrote: > it checks if any "GitHub" comment was added in last "X" minutes. If no > GitHub comments were added, then it adds that comment to the linked issue. I guess, you meant, "if any comments were added to GitHub issues". So, it does polling instead of any real-time event notifications. The Github PR comments also have a context associated with it, which are are useful while reviewing. Adding those context in the b.p.o comments can cause a churn. Instead of adding comments to b.p.o, have you considered sending only the emails notifications nosy list? Just like reitveld does right now? -- Senthil From rdmurray at bitdance.com Wed Jul 27 17:57:15 2016 From: rdmurray at bitdance.com (R. David Murray) Date: Wed, 27 Jul 2016 17:57:15 -0400 Subject: [core-workflow] GitHub reviews comments on b.p.o In-Reply-To: References: Message-ID: <20160727215716.738FCB14027@webabinitio.net> On Wed, 27 Jul 2016 14:00:09 -0700, Senthil Kumaran wrote: > On Wed, Jul 27, 2016 at 1:00 PM, Anish Shah wrote: > > it checks if any "GitHub" comment was added in last "X" minutes. If no > > GitHub comments were added, then it adds that comment to the linked issue. > > I guess, you meant, "if any comments were added to GitHub issues". > So, it does polling instead of any real-time event notifications. > > The Github PR comments also have a context associated with it, which > are are useful while reviewing. Adding those context in the b.p.o > comments can cause a churn. I've never found that context useful, myself. It should be possible to mechanically strip it. > Instead of adding comments to b.p.o, have you considered sending only > the emails notifications nosy list? Just like reitveld does right > now? The general consensus (a while back) was that the fact that reitveld doesn't update the bug tracker issue is a bug, and we're trying to fix that :) --David From senthil at uthcode.com Wed Jul 27 19:08:52 2016 From: senthil at uthcode.com (Senthil Kumaran) Date: Wed, 27 Jul 2016 16:08:52 -0700 Subject: [core-workflow] GitHub reviews comments on b.p.o In-Reply-To: <20160727215716.738FCB14027@webabinitio.net> References: <20160727215716.738FCB14027@webabinitio.net> Message-ID: On Wed, Jul 27, 2016 at 2:57 PM, R. David Murray wrote: > The general consensus (a while back) was that the fact that reitveld > doesn't update the bug tracker issue is a bug, and we're trying to fix > that :) Haha. Interesting. Github sends one email for every comment, it does not have a "draft" + "publish" comments mechanism that Rietveld has. This has the potential to create a lot of churn for some patches/reviews. From rdmurray at bitdance.com Thu Jul 28 10:45:20 2016 From: rdmurray at bitdance.com (R. David Murray) Date: Thu, 28 Jul 2016 10:45:20 -0400 Subject: [core-workflow] GitHub reviews comments on b.p.o In-Reply-To: References: <20160727215716.738FCB14027@webabinitio.net> Message-ID: <20160728144521.70C08B14027@webabinitio.net> On Wed, 27 Jul 2016 16:08:52 -0700, Senthil Kumaran wrote: > On Wed, Jul 27, 2016 at 2:57 PM, R. David Murray wrote: > > The general consensus (a while back) was that the fact that reitveld > > doesn't update the bug tracker issue is a bug, and we're trying to fix > > that :) > > Haha. Interesting. > > Github sends one email for every comment, it does not have a "draft" + > "publish" comments mechanism that Rietveld has. > This has the potential to create a lot of churn for some patches/reviews. Yes, that's the idea behind Amash's 30 minute window (or whatever it is or we decide to make it): to accumulate multiple github review comments into one post to bugs. --David From rdmurray at bitdance.com Thu Jul 28 10:48:56 2016 From: rdmurray at bitdance.com (R. David Murray) Date: Thu, 28 Jul 2016 10:48:56 -0400 Subject: [core-workflow] GitHub reviews comments on b.p.o In-Reply-To: References: <20160727215716.738FCB14027@webabinitio.net> Message-ID: <20160728144857.DB1ACB14027@webabinitio.net> On Wed, 27 Jul 2016 16:08:52 -0700, Senthil Kumaran wrote: > On Wed, Jul 27, 2016 at 2:57 PM, R. David Murray wrote: > > The general consensus (a while back) was that the fact that reitveld > > doesn't update the bug tracker issue is a bug, and we're trying to fix > > that :) > > Haha. Interesting. > > Github sends one email for every comment, it does not have a "draft" + > "publish" comments mechanism that Rietveld has. > This has the potential to create a lot of churn for some patches/reviews. The obvious alternative is to just post a link to the PR with some summary about what was posted (perhaps who and how many comments?). I don't have an opinion at this point which would be better, but the core of the proposed patch would be the same, just the output would be different. --David From senthil at uthcode.com Thu Jul 28 12:21:08 2016 From: senthil at uthcode.com (Senthil Kumaran) Date: Thu, 28 Jul 2016 09:21:08 -0700 Subject: [core-workflow] GitHub reviews comments on b.p.o In-Reply-To: <20160728144857.DB1ACB14027@webabinitio.net> References: <20160727215716.738FCB14027@webabinitio.net> <20160728144857.DB1ACB14027@webabinitio.net> Message-ID: On Thu, Jul 28, 2016 at 7:48 AM, R. David Murray wrote: > The obvious alternative is to just post a link to the PR with some > summary about what was posted (perhaps who and how many comments?). I > don't have an opinion at this point which would be better, but the core > of the proposed patch would be the same, just the output would be > different. This sounds better to me. If the person in the nosy list is interested, they can be added to the nosy list of PR, so that they can subsequent updates from there. Thank you, Senthil From encukou at gmail.com Fri Jul 29 07:09:07 2016 From: encukou at gmail.com (Petr Viktorin) Date: Fri, 29 Jul 2016 13:09:07 +0200 Subject: [core-workflow] GitHub reviews comments on b.p.o In-Reply-To: References: <20160727215716.738FCB14027@webabinitio.net> <20160728144857.DB1ACB14027@webabinitio.net> Message-ID: <83a9e1d3-0de6-f8ef-6c95-7129ab1d6dcc@gmail.com> On 07/28/2016 06:21 PM, Senthil Kumaran wrote: > On Thu, Jul 28, 2016 at 7:48 AM, R. David Murray wrote: >> The obvious alternative is to just post a link to the PR with some >> summary about what was posted (perhaps who and how many comments?). I >> don't have an opinion at this point which would be better, but the core >> of the proposed patch would be the same, just the output would be >> different. > > This sounds better to me. If the person in the nosy list is > interested, they can be added to the nosy list of PR, so that they > can subsequent updates from there. One case for copying comments is to create an archive for the case that Github goes bankrupt or turns evil. This seems very unlikely now, but Python should be planning for long-term contingencies. AFAIK there's no formal agreement between the PSF and Github that PR archives will remain accessible. From brett at python.org Fri Jul 29 13:04:47 2016 From: brett at python.org (Brett Cannon) Date: Fri, 29 Jul 2016 17:04:47 +0000 Subject: [core-workflow] GitHub reviews comments on b.p.o In-Reply-To: <83a9e1d3-0de6-f8ef-6c95-7129ab1d6dcc@gmail.com> References: <20160727215716.738FCB14027@webabinitio.net> <20160728144857.DB1ACB14027@webabinitio.net> <83a9e1d3-0de6-f8ef-6c95-7129ab1d6dcc@gmail.com> Message-ID: There has been talk in the past of setting up a cronjob somewhere that backs up all data stored at GitHub in some way for contingency purposes. I think it's a totally reasonable thing to do, but I don't plan to hold up the migration for it. On Fri, 29 Jul 2016 at 04:09 Petr Viktorin wrote: > On 07/28/2016 06:21 PM, Senthil Kumaran wrote: > > On Thu, Jul 28, 2016 at 7:48 AM, R. David Murray > wrote: > >> The obvious alternative is to just post a link to the PR with some > >> summary about what was posted (perhaps who and how many comments?). I > >> don't have an opinion at this point which would be better, but the core > >> of the proposed patch would be the same, just the output would be > >> different. > > > > This sounds better to me. If the person in the nosy list is > > interested, they can be added to the nosy list of PR, so that they > > can subsequent updates from there. > > One case for copying comments is to create an archive for the case that > Github goes bankrupt or turns evil. This seems very unlikely now, but > Python should be planning for long-term contingencies. AFAIK there's no > formal agreement between the PSF and Github that PR archives will remain > accessible. > > _______________________________________________ > 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: From soltysh at gmail.com Sat Jul 30 17:21:07 2016 From: soltysh at gmail.com (Maciej Szulik) Date: Sat, 30 Jul 2016 23:21:07 +0200 Subject: [core-workflow] GitHub reviews comments on b.p.o In-Reply-To: References: <20160727215716.738FCB14027@webabinitio.net> <20160728144857.DB1ACB14027@webabinitio.net> <83a9e1d3-0de6-f8ef-6c95-7129ab1d6dcc@gmail.com> Message-ID: I'm leaning towards just adding an information who left the comment and a link to the PR. I agree with Senthil that gh comments, especially those coming from reviews have code context, which will get lost when copying over. Besides the amount does not matter in that case, whoever is interested in looking or answering into the patch will have to go to GitHub and see what exactly it's about. I'm aware there are cases you just want to read the comment and don't do anything yet, but these are rare cases we can initially ignore. Let's start simple and we can always get back to this topic. On Fri, Jul 29, 2016 at 7:04 PM, Brett Cannon wrote: > There has been talk in the past of setting up a cronjob somewhere that > backs up all data stored at GitHub in some way for contingency purposes. I > think it's a totally reasonable thing to do, but I don't plan to hold up > the migration for it. > > On Fri, 29 Jul 2016 at 04:09 Petr Viktorin wrote: > >> On 07/28/2016 06:21 PM, Senthil Kumaran wrote: >> > On Thu, Jul 28, 2016 at 7:48 AM, R. David Murray >> wrote: >> >> The obvious alternative is to just post a link to the PR with some >> >> summary about what was posted (perhaps who and how many comments?). I >> >> don't have an opinion at this point which would be better, but the core >> >> of the proposed patch would be the same, just the output would be >> >> different. >> > >> > This sounds better to me. If the person in the nosy list is >> > interested, they can be added to the nosy list of PR, so that they >> > can subsequent updates from there. >> >> One case for copying comments is to create an archive for the case that >> Github goes bankrupt or turns evil. This seems very unlikely now, but >> Python should be planning for long-term contingencies. AFAIK there's no >> formal agreement between the PSF and Github that PR archives will remain >> accessible. >> >> _______________________________________________ >> 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: