From ethan at stoneleaf.us  Wed Feb  1 00:58:47 2017
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 31 Jan 2017 21:58:47 -0800
Subject: [python-committers] New team member intro
In-Reply-To: <CAGbohnZ53gpC8XH_npmytaFSitT3B9X__gP7O5-SS1yhhaTzyg@mail.gmail.com>
References: <CAGbohnZ53gpC8XH_npmytaFSitT3B9X__gP7O5-SS1yhhaTzyg@mail.gmail.com>
Message-ID: <58917917.6070709@stoneleaf.us>

On 01/30/2017 03:10 PM, Mariatta Wijaya wrote:

> Looking forward contributing more and working with everyone here :)

Welcome and congratulations!

--
~Ethan~

From ncoghlan at gmail.com  Wed Feb  1 15:26:30 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 1 Feb 2017 21:26:30 +0100
Subject: [python-committers] New team member intro
In-Reply-To: <CAP1=2W4b+qGkQ=JkYCMfZcK3OJr8aWEzd__DnhRDk-VeuJxnug@mail.gmail.com>
References: <CAGbohnZ53gpC8XH_npmytaFSitT3B9X__gP7O5-SS1yhhaTzyg@mail.gmail.com>
 <CAPOVWOSrWkHaC9Gv3eiLW=_xpW3jpVsiz4ZFiGzxefW9ch13ig@mail.gmail.com>
 <CAGbohnbZ2V+mW4Yrts4fjToyeYEtTcqb_SwtfOvPMw_eai47fw@mail.gmail.com>
 <CAP1=2W4b+qGkQ=JkYCMfZcK3OJr8aWEzd__DnhRDk-VeuJxnug@mail.gmail.com>
Message-ID: <CADiSq7fw=cGVs_R10UVi47gcA2LK1+46atwh60kA9bi_tUDEWQ@mail.gmail.com>

On 31 January 2017 at 19:13, Brett Cannon <brett at python.org> wrote:
> I wonder, what city has the most number of core devs (depending on how you
> define "metropolitan area" I'm fairly certain SF or Silicon Valley wins the
> metro question)? Vancouver now has two. :)

If folks have their location set in the GitHub profile, that data can
be pulled to some level of granularity from the mirror repo (and the
real one soon enough)

I'm also hoping we may some day get reasonable country-granularity
data from https://docs.python.org/devguide/motivations.html, but it
looks like most folks still aren't too keen on filling that out at
this point :)

Cheers,
Nick.

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

From senthil at uthcode.com  Wed Feb  1 16:43:01 2017
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 1 Feb 2017 13:43:01 -0800
Subject: [python-committers] New team member intro
In-Reply-To: <CADiSq7fw=cGVs_R10UVi47gcA2LK1+46atwh60kA9bi_tUDEWQ@mail.gmail.com>
References: <CAGbohnZ53gpC8XH_npmytaFSitT3B9X__gP7O5-SS1yhhaTzyg@mail.gmail.com>
 <CAPOVWOSrWkHaC9Gv3eiLW=_xpW3jpVsiz4ZFiGzxefW9ch13ig@mail.gmail.com>
 <CAGbohnbZ2V+mW4Yrts4fjToyeYEtTcqb_SwtfOvPMw_eai47fw@mail.gmail.com>
 <CAP1=2W4b+qGkQ=JkYCMfZcK3OJr8aWEzd__DnhRDk-VeuJxnug@mail.gmail.com>
 <CADiSq7fw=cGVs_R10UVi47gcA2LK1+46atwh60kA9bi_tUDEWQ@mail.gmail.com>
Message-ID: <CAPOVWOSmeir+NYteKB8mS2oraOdMxUfg07CKtQQSLboMGgRWTw@mail.gmail.com>

On Wed, Feb 1, 2017 at 12:26 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> I'm also hoping we may some day get reasonable country-granularity
> data from https://docs.python.org/devguide/motivations.html, but it
> looks like most folks still aren't too keen on filling that out at
> this point :)

Initially, I thought, the goal was to express the "intrinsic"
motivations out on that page.
I was negative for that purpose. IIRC, there was a debate on that too.

It looks like we like can just mention our name, and generic details.
Many core devs will be happy to just do it, like some of us have already done.

-- 
Senthil

From ncoghlan at gmail.com  Wed Feb  1 17:33:16 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 1 Feb 2017 23:33:16 +0100
Subject: [python-committers] New team member intro
In-Reply-To: <CAPOVWOSmeir+NYteKB8mS2oraOdMxUfg07CKtQQSLboMGgRWTw@mail.gmail.com>
References: <CAGbohnZ53gpC8XH_npmytaFSitT3B9X__gP7O5-SS1yhhaTzyg@mail.gmail.com>
 <CAPOVWOSrWkHaC9Gv3eiLW=_xpW3jpVsiz4ZFiGzxefW9ch13ig@mail.gmail.com>
 <CAGbohnbZ2V+mW4Yrts4fjToyeYEtTcqb_SwtfOvPMw_eai47fw@mail.gmail.com>
 <CAP1=2W4b+qGkQ=JkYCMfZcK3OJr8aWEzd__DnhRDk-VeuJxnug@mail.gmail.com>
 <CADiSq7fw=cGVs_R10UVi47gcA2LK1+46atwh60kA9bi_tUDEWQ@mail.gmail.com>
 <CAPOVWOSmeir+NYteKB8mS2oraOdMxUfg07CKtQQSLboMGgRWTw@mail.gmail.com>
Message-ID: <CADiSq7dEZ76ukNmUQZTE+pyFgRyyQ_N7PewPP-EY9G2GJRbryQ@mail.gmail.com>

On 1 February 2017 at 22:43, Senthil Kumaran <senthil at uthcode.com> wrote:
> On Wed, Feb 1, 2017 at 12:26 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> I'm also hoping we may some day get reasonable country-granularity
>> data from https://docs.python.org/devguide/motivations.html, but it
>> looks like most folks still aren't too keen on filling that out at
>> this point :)
>
> Initially, I thought, the goal was to express the "intrinsic"
> motivations out on that page.

It was, as *I* wanted a place to record that explicitly.

> I was negative for that purpose. IIRC, there was a debate on that too.

Yeah, after a few folks provided feedback I changed the comments in
the source file to make it clear that "just the facts" entries were
fine, and providing more details than that was entirely optional.

Cheers,
Nick.

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

From brett at python.org  Thu Feb  2 00:50:12 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 02 Feb 2017 05:50:12 +0000
Subject: [python-committers] Any blackout dates to NOT migrate to GitHub?
Message-ID: <CAP1=2W6vQdFO1X3ckfTvvngaCUB-Z+wuC837a571yK_K6qkqnA@mail.gmail.com>

All the blockers for migrating to GitHub are done! That means it's time to
schedule the migration. Are there any days that people would really prefer
we *don't* do the migration on? I'm hoping to do it next week and
definitely this month. I have already asked Ned and Larry and they are fine
with any date this month. So if there's some date people don't want the
migration to happen on (e.g. running a sprint), please speak up. Otherwise
I will schedule among those helping me with the migration and get this done!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170202/d1d724f0/attachment.html>

From kushaldas at gmail.com  Thu Feb  2 00:57:30 2017
From: kushaldas at gmail.com (Kushal Das)
Date: Thu, 2 Feb 2017 11:27:30 +0530
Subject: [python-committers] Any blackout dates to NOT migrate to GitHub?
In-Reply-To: <CAP1=2W6vQdFO1X3ckfTvvngaCUB-Z+wuC837a571yK_K6qkqnA@mail.gmail.com>
References: <CAP1=2W6vQdFO1X3ckfTvvngaCUB-Z+wuC837a571yK_K6qkqnA@mail.gmail.com>
Message-ID: <CAAzeMbwqwHaLJzmfk7Cg4R63VTX1JCDY_mFoTgtn2h9pTdx4VA@mail.gmail.com>

On Thu, Feb 2, 2017 at 11:20 AM, Brett Cannon <brett at python.org> wrote:
> All the blockers for migrating to GitHub are done! That means it's time to
> schedule the migration. Are there any days that people would really prefer
> we don't do the migration on? I'm hoping to do it next week and definitely
> this month. I have already asked Ned and Larry and they are fine with any
> date this month. So if there's some date people don't want the migration to
> happen on (e.g. running a sprint), please speak up. Otherwise I will
> schedule among those helping me with the migration and get this done!

We are having a developer sprint on 18-19th of February in PyCon Pune.
Maybe we can skip those two days  :)

Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
http://kushaldas.in

From brett at python.org  Thu Feb  2 12:36:29 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 02 Feb 2017 17:36:29 +0000
Subject: [python-committers] Any blackout dates to NOT migrate to GitHub?
In-Reply-To: <CAAzeMbwqwHaLJzmfk7Cg4R63VTX1JCDY_mFoTgtn2h9pTdx4VA@mail.gmail.com>
References: <CAP1=2W6vQdFO1X3ckfTvvngaCUB-Z+wuC837a571yK_K6qkqnA@mail.gmail.com>
 <CAAzeMbwqwHaLJzmfk7Cg4R63VTX1JCDY_mFoTgtn2h9pTdx4VA@mail.gmail.com>
Message-ID: <CAP1=2W5uGyOwU_eT7_ZbnYCL6-TC-9uOfwJTaOaGbufhMJ_y8w@mail.gmail.com>

Consider it blocked out (and motivation to actually get the migration done
before then so your sprint can test out the new workflow :) .

On Wed, 1 Feb 2017 at 21:57 Kushal Das <kushaldas at gmail.com> wrote:

> On Thu, Feb 2, 2017 at 11:20 AM, Brett Cannon <brett at python.org> wrote:
> > All the blockers for migrating to GitHub are done! That means it's time
> to
> > schedule the migration. Are there any days that people would really
> prefer
> > we don't do the migration on? I'm hoping to do it next week and
> definitely
> > this month. I have already asked Ned and Larry and they are fine with any
> > date this month. So if there's some date people don't want the migration
> to
> > happen on (e.g. running a sprint), please speak up. Otherwise I will
> > schedule among those helping me with the migration and get this done!
>
> We are having a developer sprint on 18-19th of February in PyCon Pune.
> Maybe we can skip those two days  :)
>
> Kushal
> --
> Fedora Cloud Engineer
> CPython Core Developer
> http://kushaldas.in
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170202/6b0dbf20/attachment.html>

From brett at python.org  Sun Feb  5 19:25:00 2017
From: brett at python.org (Brett Cannon)
Date: Mon, 06 Feb 2017 00:25:00 +0000
Subject: [python-committers] GitHub migration scheduled for Friday, Feb 10
Message-ID: <CAP1=2W5cgB2Yo4-HJ0Gvh55w1o0MF0A7ad6O--0VJoCkERNhKQ@mail.gmail.com>

To keep things simple, just assume you should not commit to Mercurial on
Feb 10 no matter your timezone. The hope is that the migration will go
smoothly enough that commits can be accepted starting on Feb 11 (or sooner;
I'll email once everything has moved over). The only thing that might take
a couple of days to straighten out is the building of docs.python.org (it's
planned to happen on Friday, but if the devguide was any indication there
will be some unforseen hiccup). Also realize that the current cpython
mirror on GitHub won't survive the migration, so plan to generate patches
for any clones you have to move to the new repo (and Victor should plan to
have his PRs get closed on the mirror).

I will be writing a doc that outlines the key changes in how things will be
handled so people can get started quickly. The devguide will also be
appropriately updated (it's mostly already updated and can be seen at
https://cpython-devguide.readthedocs.io/en/github/, but there's one change
that it doesn't cover in regards to specifying issue numbers).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170206/3f79af15/attachment.html>

From barry at python.org  Mon Feb  6 09:41:52 2017
From: barry at python.org (Barry Warsaw)
Date: Mon, 6 Feb 2017 09:41:52 -0500
Subject: [python-committers] GitHub migration scheduled for Friday,
 Feb 10
In-Reply-To: <CAP1=2W5cgB2Yo4-HJ0Gvh55w1o0MF0A7ad6O--0VJoCkERNhKQ@mail.gmail.com>
References: <CAP1=2W5cgB2Yo4-HJ0Gvh55w1o0MF0A7ad6O--0VJoCkERNhKQ@mail.gmail.com>
Message-ID: <20170206094152.602288d1@subdivisions.wooz.org>

On Feb 06, 2017, at 12:25 AM, Brett Cannon wrote:

>To keep things simple, just assume you should not commit to Mercurial on
>Feb 10 no matter your timezone.

Happy birthday to me!  Thanks Brett and everyone else for working on the
migration.

Cheers,
-Barry

From ncoghlan at gmail.com  Mon Feb  6 10:07:10 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 6 Feb 2017 16:07:10 +0100
Subject: [python-committers] GitHub migration scheduled for Friday,
 Feb 10
In-Reply-To: <20170206094152.602288d1@subdivisions.wooz.org>
References: <CAP1=2W5cgB2Yo4-HJ0Gvh55w1o0MF0A7ad6O--0VJoCkERNhKQ@mail.gmail.com>
 <20170206094152.602288d1@subdivisions.wooz.org>
Message-ID: <CADiSq7ewGvq4x_p+KDAq_NUpom-n0_==ZQN3QQJOenBkanVorg@mail.gmail.com>

On 6 February 2017 at 15:41, Barry Warsaw <barry at python.org> wrote:
> On Feb 06, 2017, at 12:25 AM, Brett Cannon wrote:
>
>>To keep things simple, just assume you should not commit to Mercurial on
>>Feb 10 no matter your timezone.
>
> Happy birthday to me!  Thanks Brett and everyone else for working on the
> migration.

Indeed, thank you!

Getting from "Wouldn't it be nice if we had a more convenient
workflow?" to actually having one is a major undertaking for a project
of CPython's size and age, and y'all have managed to come together and
actually deliver it :)

Cheers,
Nick.

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

From brett at python.org  Thu Feb  9 12:02:54 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 09 Feb 2017 17:02:54 +0000
Subject: [python-committers] Python 3.4.6 docs not up at docs.python.org
Message-ID: <CAP1=2W7vX9icQJTAHY9Op=SaxfKU_R6SBD4HKShsPshtYJ-E5g@mail.gmail.com>

Looks like the docs are still pointing at 3.4.5.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170209/febc192b/attachment.html>

From nad at python.org  Thu Feb  9 12:21:43 2017
From: nad at python.org (Ned Deily)
Date: Thu, 9 Feb 2017 12:21:43 -0500
Subject: [python-committers] Python 3.4.6 docs not up at docs.python.org
In-Reply-To: <CAP1=2W7vX9icQJTAHY9Op=SaxfKU_R6SBD4HKShsPshtYJ-E5g@mail.gmail.com>
References: <CAP1=2W7vX9icQJTAHY9Op=SaxfKU_R6SBD4HKShsPshtYJ-E5g@mail.gmail.com>
Message-ID: <5D7C1178-E3A7-4B39-8619-1E8FB207A528@python.org>

On Feb 9, 2017, at 12:02, Brett Cannon <brett at python.org> wrote:
> 
> Looks like the docs are still pointing at 3.4.5.

Larry is aware of the problem and will fix it in the near future.

--
  Ned Deily
  nad at python.org -- []


From brett at python.org  Fri Feb 10 10:55:47 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 10 Feb 2017 15:55:47 +0000
Subject: [python-committers] REMINDER: GitHub migration is scheduled for
 today
Message-ID: <CAP1=2W4iU4rRAMdbM_5hCupF567T4LXTnkrK7v8ikhh_UJ7LxA@mail.gmail.com>

Assuming you can't commit to Mercurial anymore and the next email from me
will either be an introduction email to our new workflow or me apologizing
for something going horribly wrong. Either way I'm hoping you will hear
from me later today. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170210/c9cd0dc1/attachment.html>

From mail at timgolden.me.uk  Fri Feb 10 11:00:43 2017
From: mail at timgolden.me.uk (Tim Golden)
Date: Fri, 10 Feb 2017 16:00:43 +0000
Subject: [python-committers] REMINDER: GitHub migration is scheduled for
 today
In-Reply-To: <CAP1=2W4iU4rRAMdbM_5hCupF567T4LXTnkrK7v8ikhh_UJ7LxA@mail.gmail.com>
References: <CAP1=2W4iU4rRAMdbM_5hCupF567T4LXTnkrK7v8ikhh_UJ7LxA@mail.gmail.com>
Message-ID: <f5a26ed4-8e09-fbfb-6a1b-8ade99855280@timgolden.me.uk>

On 10/02/2017 15:55, Brett Cannon wrote:
> Assuming you can't commit to Mercurial anymore and the next email from
> me will either be an introduction email to our new workflow or me
> apologizing for something going horribly wrong. Either way I'm hoping
> you will hear from me later today. :)

Good luck, and thanks to you and the team for all the hard work

TJG


From ericsnowcurrently at gmail.com  Fri Feb 10 11:10:35 2017
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Fri, 10 Feb 2017 09:10:35 -0700
Subject: [python-committers] REMINDER: GitHub migration is scheduled for
 today
In-Reply-To: <f5a26ed4-8e09-fbfb-6a1b-8ade99855280@timgolden.me.uk>
References: <CAP1=2W4iU4rRAMdbM_5hCupF567T4LXTnkrK7v8ikhh_UJ7LxA@mail.gmail.com>
 <f5a26ed4-8e09-fbfb-6a1b-8ade99855280@timgolden.me.uk>
Message-ID: <CALFfu7Awi6DGdVF3d1wsPKKwccqkNqinV1wsR22wdhCJcMuiZQ@mail.gmail.com>

On Fri, Feb 10, 2017 at 9:00 AM, Tim Golden <mail at timgolden.me.uk> wrote:
> Good luck, and thanks to you and the team for all the hard work

A big +1!

-eric

From mariatta.wijaya at gmail.com  Fri Feb 10 11:58:48 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Fri, 10 Feb 2017 08:58:48 -0800
Subject: [python-committers] REMINDER: GitHub migration is scheduled for
 today
In-Reply-To: <CAP1=2W4iU4rRAMdbM_5hCupF567T4LXTnkrK7v8ikhh_UJ7LxA@mail.gmail.com>
References: <CAP1=2W4iU4rRAMdbM_5hCupF567T4LXTnkrK7v8ikhh_UJ7LxA@mail.gmail.com>
Message-ID: <CAGbohnbk=LD0E4aLbrBFkDZN4prkXS1EJ3tiTpGEhF1Lv8US_g@mail.gmail.com>

So exciting!
Good luck and thanks for all the hard work!


On Feb 10, 2017 7:56 AM, "Brett Cannon" <brett at python.org> wrote:

> Assuming you can't commit to Mercurial anymore and the next email from me
> will either be an introduction email to our new workflow or me apologizing
> for something going horribly wrong. Either way I'm hoping you will hear
> from me later today. :)
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170210/f2b45f2c/attachment.html>

From ethan at stoneleaf.us  Fri Feb 10 12:01:37 2017
From: ethan at stoneleaf.us (Ethan Furman)
Date: Fri, 10 Feb 2017 09:01:37 -0800
Subject: [python-committers] REMINDER: GitHub migration is scheduled for
 today
In-Reply-To: <CAP1=2W4iU4rRAMdbM_5hCupF567T4LXTnkrK7v8ikhh_UJ7LxA@mail.gmail.com>
References: <CAP1=2W4iU4rRAMdbM_5hCupF567T4LXTnkrK7v8ikhh_UJ7LxA@mail.gmail.com>
Message-ID: <589DF1F1.10603@stoneleaf.us>

On 02/10/2017 07:55 AM, Brett Cannon wrote:

> Assume you can't commit to Mercurial anymore and the next email from me
>  will either be an introduction email to our new workflow or me apologizing
>  for something going horribly wrong. Either way I'm hoping you will hear
>  from me later today. :)

Either way you're our hero!  Thank you, thank you!

--
~Ethan~

From brett at python.org  Fri Feb 10 12:07:31 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 10 Feb 2017 17:07:31 +0000
Subject: [python-committers] REMINDER: GitHub migration is scheduled for
 today
In-Reply-To: <CAGbohnbk=LD0E4aLbrBFkDZN4prkXS1EJ3tiTpGEhF1Lv8US_g@mail.gmail.com>
References: <CAP1=2W4iU4rRAMdbM_5hCupF567T4LXTnkrK7v8ikhh_UJ7LxA@mail.gmail.com>
 <CAGbohnbk=LD0E4aLbrBFkDZN4prkXS1EJ3tiTpGEhF1Lv8US_g@mail.gmail.com>
Message-ID: <CAP1=2W5w0gjF-ZUn7m4WxyAsPGErk-11m4zQHCB3DumaRypcLg@mail.gmail.com>

On Fri, 10 Feb 2017 at 08:58 Mariatta Wijaya <mariatta.wijaya at gmail.com>
wrote:

> So exciting!
> Good luck and thanks for all the hard work!
>

You're welcome, but please save the "thank you"s until after the migration
is successful. :)

-Brett


>
>
> On Feb 10, 2017 7:56 AM, "Brett Cannon" <brett at python.org> wrote:
>
> Assuming you can't commit to Mercurial anymore and the next email from me
> will either be an introduction email to our new workflow or me apologizing
> for something going horribly wrong. Either way I'm hoping you will hear
> from me later today. :)
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170210/7f18bf8e/attachment.html>

From brett at python.org  Fri Feb 10 18:19:24 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 10 Feb 2017 23:19:24 +0000
Subject: [python-committers] We are now live on GitHub!
Message-ID: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>

[rendered version:
https://paper.dropbox.com/doc/CPython-workflow-changes-mx1k8G6M0rg5JLy80F1r6
]

# CPython workflow changes
After more than two years, our new GitHub workflow is ready to accept
changes (you can look back to my first ?[vision statement](
https://mail.python.org/pipermail/python-dev/2014-December/137472.html)? on
changing our workflow to see how things have changed since I started
working on this)! I hope you are all excited to see this finished; I know
my wife is very excited as she?s tired of listening to me talk about it for
a third of our marriage. ;)

# Thanks

First and foremost, I want to thank everyone who helped with this. Thanks
to Donald and Barry for writing the initial PEPs proposing [GitHub](
https://www.python.org/dev/peps/pep-0481/) and [GitLab](
https://www.python.org/dev/peps/pep-0507/) and Nick [pre-proposing
RhodeCode](https://www.python.org/dev/peps/pep-0474/). Thanks to everyone
on [core-workflow](https://mail.python.org/mailman/listinfo/core-workflow)
for helping out with various discussion (and which will continue to host
discussions on future improvements on our workflow). Thanks to Ezio,
Maciej, and Anish Shah for helping with the changes required to
bugs.python.org in order to keep the issue tracker around. Thanks to the
infrastructure team for helping deal with the migration of the [peps](
https://github.com/python/peps) and [devguide](
https://github.com/python/devguide) repos (especially Donald and Ernest).
Thanks to Senthil for doing the conversion of the repo itself. Thanks to
Benjamin for helping with hg.python.org stuff. Thanks to Zach for helping
with the buildbots (and the devguide). Thanks to Mariatta, Carol Willing,
Berker, Oleg, and St?phane Wirtel for helping with the devguide. There are
also plenty of other people who have provided feedback over the past 2
years on mailing lists and in-person.

# What has changed

The documentation in the [devguide](https://cpython-devguide.readthedocs.io)
should be up-to-date, so don?t worry about keeping this around as a
reference. Consider this more of an announcement letter to get people
quickly up-to-speed and excited about the new workflow.

## The location of the code repository

CPython?s code now lives at https://github.com/python/cpython .
hg.python.org/cpython is and will stay read-only (no determination has been
made as to how long the Mercurial repository will be kept running). It
should also be mentioned that we are doing squash commits and not rebased
commits or merge commits as some projects on GitHub do. This basically
means we will continue to have a single contribution lead to a single
commit, keeping our history linear and compact.

To up the bus factor on the new repository, I have set up a team for
[Python release managers](
https://github.com/orgs/python/teams/python-release-managers) and made them
administrators on the repository. I don?t necessarily expect RMs to use
this power, but it?s there in case any of them need to change a setting in
order to get a release out (to be upfront about it, I?m also in the team as
its creator, but I have administrative privileges for the [Python team](
https://github.com/python) on GitHub so it doesn?t change what I?m able to
do).

## Specifying issue numbers

Traditionally we have specified issues as ?Issue #NNNN?. The problem with
this format is that [GitHub automatically links](
https://help.github.com/articles/autolinked-references-and-urls/#issues-and-pull-requests)
text in this format to GitHub issues and pull requests. While our
repository will initially have no issues or PRs to automatically link to,
this might not be true long-term (GitHub does the automatic linking eagerly
at push time, so there?s no worry for older commit messages; we actually
almost mutated the history to match the new format but in the end I made
the decision not to as I didn?t consult with python-committers prior to the
migration to make sure such a change was acceptable to everyone).

To avoid this issue we are going to start specifying issues as ?bpo-NNNN?.
This clearly delineates that issue numbers directly relate to
bugs.python.org since ?[namespaces are one honking great idea](
https://www.python.org/dev/peps/pep-0020/)?. This is also a format that
GitHub supports ? ?GH-NNNN? ? as well as JIRA who [lets you specify the
prefix](
https://confluence.atlassian.com/adminjiraserver072/changing-the-project-key-format-828787722.html),
so there?s precedent for choosing it. This change applies both to
`[Misc/NEWS](
https://cpython-devguide.readthedocs.io/committing.html#what-s-new-and-news-entries)`
and in [commit messages](
https://cpython-devguide.readthedocs.io/committing.html#commit-messages).
Mentioning an issue this way in a pull request title or comment will
connect the PR to the corresponding issue on bugs.python.org. Mentioning an
issue this way in a commit message will cause a comment to show up in the
issue relating to the commit.

## Cherry-picking instead of merging

When a patch has spanned more than one version/branch we have always done a
forward merge.  The common issue with this, though, is it leads to racing
with other committers from when you make to your initial commit in the
oldest version/branch to pushing to hg.python.org on the newest
version/branch. There was also the problem of having to remember that
Python 2.7 is a special branch which was never merged forward.

To deal with these issues we will use [cherry-picking](
https://cpython-devguide.readthedocs.io/committing.html#backporting-changes-to-python-3-6-or-older-version)
going forward. This allows changes to be pulled into other branches as
independent commits. This prevents any commit races with other core
developers as we have traditionally needed to deal with when doing forward
merges that span e.g. three branches. It also allows using CI to easily
verify a change works if each cherry-pick is done as a separate pull
request. The Python 2.7 branch also stops being a special case when
backporting. It also prevents potential issues stemming from contributors
submitting pull requests against the master branch by default and not the
oldest branch a change should be applied to. Finally, this also removes the
discussion of whether a change should be backported or not from blocking
the commit into master to begin with.

Labels will be provided for people to use to help track any cherry-picking
that needs to occur for a pull request (e.g. ?backport to 3.6?). I also
left the ?bug? and ?enhancement? labels to help classify PRs (adding more
labels is easy so we can do that as our experience and workflow organically
converge towards common practices).

## Protected branches

All feature branches have been marked as [protected](
https://help.github.com/articles/about-protected-branches/). This means
that feature branches cannot be deleted nor can they be pushed to directly.
The latter will be the biggest change as it means all changes must go
through a pull request. This helps make sure that there are no accidental
breakage of code (I know I have done this multiple times when in a rush and
I didn?t take my time when preparing a commit). This also means that all
core developers follow the same development workflow as any other
contributor. This not only allows all core developers to be able to help
any other contributors with our workflow, but it also helps make sure we
are aware of any sticking points in the contributor process so that we can
all work towards resolving them for everyone?s benefit. (If experience
shows that this is too much overhead we can turn this off.)

All feature branches that are in security-only mode are locked down so that
only [Python release managers](
https://github.com/orgs/python/teams/python-release-managers) can approve
pull requests to them. For all branches that have reached EOL, no one is
able to push to them. I expect that RMs will also use this feature when
they are ready to gate all commits to a branch on their approval (e.g. when
a release reaches RC, maybe even beta if they choose to go that far).

# What has improved
## Accepting PRs through GitHub?s web UI

While using hg.python.org, all commits had to be done through Mercurial?s
CLI. With the move to GitHub we gain the ability to accept pull requests
through a web UI. While this will only accept the change into the branch it
was submitted against (which can be changed in the web UI), for situations
where a change does not need to be backported it will allow for easier
acceptance of a change. (When a change does need to be backported this is
when you need to cherry-pick and that requires using the git CLI). If a
change does need to be cherry-picked into an older branch you can either
wait to accept the PR when you have a clone to work with or accept the
change into master now and then cherry-pick later when you have a clone
available.

## Continuous integration

Previously changes required running the test suite manually along with
verifying various other things like the documentation building. Moving to
GitHub allows us to leverage the Travis continuous integration service to
test several things in parallel automatically for each pull request:


1. Debug build under gcc
2. Debug build under clang
3. Documentation is valid and has no stale links
4. Python.h C++ compatibility

While this doesn?t solve all testing scenarios (e.g. this doesn?t test a
macOS or Windows-related change due to the added hours it take for a PR to
be ?green? when run on Travis for macOS or AppVeyor for Windows), it does
help with the common case of a cross-platform change. (There is an [open
issue](https://github.com/python/core-workflow/issues/14) to add some code
so that these tests only run when appropriate files have changed so that
e.g. fixing a spelling mistake doesn?t run the test suite.)

It should be mentioned that status checks on issues are **not** required
prior to committing a pull request. While this may be a good idea
long-term, until we know that our test suite is stable enough to not have
regular flaky tests this would be more trouble than it?s worth (GitHub does
visibly show, though, when not all status checks have passed so you won?t
easily ignore this situation either).

## Code coverage

Traditionally the code coverage of our tests was only known when someone
ran the test suite manually under something like [coverage.py](
https://coverage.readthedocs.io). Even when someone did generate a coverage
report it was generally not shared with other developers, and so it wasn?t
widely known if a pull request increased or lowered test coverage.

With the move to GitHub we are able to use [Codecov](https://codecov.io/)
to calculate code coverage for each pull request. This also implicitly
tests a non-debug build as that?s used to make the coverage results run
faster. It should be noted, though, that some tests are skipped due to them
holding up the coverage run from completing. (There is an [open issue](
https://github.com/python/core-workflow/issues/18) to use coverage.py?s
fullcoverage hack so that the coverage report can even be accurate for
modules imported during interpreter startup.)

## CLA enforcement

To tell if someone has signed the PSF contributor license agreement you
have to look to see if they have an asterisk by their name on the issue
tracker. Unfortunately this is a passive thing to need to check for and is
easily forgotten. Thanks to GitHub?s webhook events and developer API we
now have a bot which checks if the contributor(s) to a pull request have
signed the CLA, adding an appropriate label to the PR to signal the CLA
signing status (the bot is named [The Knights Who Say Ni](
https://github.com/python/the-knights-who-say-ni)). If the contributor(s)
have not signed the CLA then a message is left on the PR explaining how to
rectify the issue (it?s either they need to connect their GitHub account to
their bugs.python.org account or they need to sign the CLA; there?s also is
an easter egg that occasionally appears in the message).

If a contributor does end up fixing the issue that leads to the bot
thinking the contributor had not signed the CLA, you can remove the ?CLA
not signed? label and the bot will recheck the PR and add the appropriate
label (this also happens automatically if any code changes are made to the
PR). If for some the reason the bot has a hiccup then no label will be
applied (this is to act as a safeguard against false-negatives and to make
it easy to spot when something has gone wrong due to the absence of either
a ?CLA signed? or ?CLA not signed? label). To trigger the bot again you can
simply apply the ?CLA not signed? label and then remove it.

## Contribution guidelines

There is now a `[.github/CONTRIBUTING.rst](
https://github.com/python/cpython/blob/master/.github/CONTRIBUTING.rst)`
file which gives general info on contributing. Primarily it has all the
various build status badges and links, link to the devguide and an overview
of how we differ from most GitHub projects, and a mention of the CoC. For
core devs I suspect the badge list for all active branches will be useful
to know when something is broken (I am only listing the test coverage for
the master branch to prevent encouraging people spending time trying to
increase test coverage for bugfix-only branches) .

# The future

This isn?t here for discussion per-se, but to let people know what I am
thinking should change next. If you want to help or discuss anything in
this section, please subscribe to core-workflow and participate there.
Ideas are also tracked on the [core-workflow issue tracker](
https://github.com/python/core-workflow/issues) (where there are other
ideas for improvements beyond the two listed below).

First, we need to solve the Misc/NEWS problem. The [plan](
https://github.com/python/core-workflow/issues/6) is to move to individual
files per NEWS entry and then have a script to roll them all up into the
NEWS file at release time. This will do away with merge conflicts which has
always been the biggest hassle when a change spanned versions.

Second, we will probably develop some solution to [automatically generate
cherry-picking PRs](https://github.com/python/core-workflow/issues/8). This
plus the Misc/NEWS solution should be enough to allow most patches to be
accepted through the web UI entirely.

All the other changes are nice-to-have, but I think these two will lead to
the greatest improvement to our workflow and get us far beyond the workflow
we had on hg.python.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170210/2443028b/attachment-0001.html>

From antoine at python.org  Fri Feb 10 18:49:26 2017
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 11 Feb 2017 00:49:26 +0100
Subject: [python-committers] We are now live on GitHub!
In-Reply-To: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
Message-ID: <f6f80b72-64ee-882a-620e-b990fffb50ac@python.org>


Le 11/02/2017 ? 00:19, Brett Cannon a ?crit :
> 
> # What has improved
> ## Accepting PRs through GitHub?s web UI
> 
> While using hg.python.org <http://hg.python.org>, all commits had to be
> done through Mercurial?s CLI. With the move to GitHub we gain the
> ability to accept pull requests through a web UI. While this will only
> accept the change into the branch it was submitted against (which can be
> changed in the web UI), for situations where a change does not need to
> be backported it will allow for easier acceptance of a change. (When a
> change does need to be backported this is when you need to cherry-pick
> and that requires using the git CLI). If a change does need to be
> cherry-picked into an older branch you can either wait to accept the PR
> when you have a clone to work with or accept the change into master now
> and then cherry-pick later when you have a clone available.

To make sure I'm understanding this, this means any cherry-pick goes
through its own PR, right?  i.e. if a change has to go into master, 3.6
and 2.7, three PRs have to be opened?

(and what do you mean with "when you have a clone available"?)

> While this doesn?t solve all testing scenarios (e.g. this doesn?t test a
> macOS or Windows-related change due to the added hours it take for a PR
> to be ?green? when run on Travis for macOS or AppVeyor for Windows),

In my experience, build times on AppVeyor have recently become more
competitive with Travis-CI (though mostly because Travis-CI seems to
have become slower).  However, AppVeyor doesn't seem to schedule several
build configurations in parallel, so this is best used as a smoke test
with a single build configuration (also, the test suite could be run in
a less thorough mode).


Thanks for all the work!

Regards

Antoine.

From donald at stufft.io  Fri Feb 10 19:10:57 2017
From: donald at stufft.io (Donald Stufft)
Date: Fri, 10 Feb 2017 19:10:57 -0500
Subject: [python-committers] We are now live on GitHub!
In-Reply-To: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
Message-ID: <D7144909-CBE5-4B82-83AB-958FABD703E0@stufft.io>


> On Feb 10, 2017, at 6:19 PM, Brett Cannon <brett at python.org> wrote:
> 
> While this doesn?t solve all testing scenarios (e.g. this doesn?t test a macOS or Windows-related change due to the added hours it take for a PR to be ?green? when run on Travis for macOS or AppVeyor for Windows)


Just an FYI, I was talking to a friend in Travis and he suggests in the next few weeks they?re going to get a lot more macOS capacity. We might want to try this again in a few weeks and see if their new capacity is enough that the lead time is good enough.

?
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170210/a926d9da/attachment.html>

From brett at python.org  Fri Feb 10 19:12:05 2017
From: brett at python.org (Brett Cannon)
Date: Sat, 11 Feb 2017 00:12:05 +0000
Subject: [python-committers] We are now live on GitHub!
In-Reply-To: <f6f80b72-64ee-882a-620e-b990fffb50ac@python.org>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
 <f6f80b72-64ee-882a-620e-b990fffb50ac@python.org>
Message-ID: <CAP1=2W7zUm0BGM1e4KcbSX=dAgEfGHefUti5oM_ntRc2MXVkSA@mail.gmail.com>

On Fri, 10 Feb 2017 at 15:50 Antoine Pitrou <antoine at python.org> wrote:

>
> Le 11/02/2017 ? 00:19, Brett Cannon a ?crit :
> >
> > # What has improved
> > ## Accepting PRs through GitHub?s web UI
> >
> > While using hg.python.org <http://hg.python.org>, all commits had to be
> > done through Mercurial?s CLI. With the move to GitHub we gain the
> > ability to accept pull requests through a web UI. While this will only
> > accept the change into the branch it was submitted against (which can be
> > changed in the web UI), for situations where a change does not need to
> > be backported it will allow for easier acceptance of a change. (When a
> > change does need to be backported this is when you need to cherry-pick
> > and that requires using the git CLI). If a change does need to be
> > cherry-picked into an older branch you can either wait to accept the PR
> > when you have a clone to work with or accept the change into master now
> > and then cherry-pick later when you have a clone available.
>
> To make sure I'm understanding this, this means any cherry-pick goes
> through its own PR, right?  i.e. if a change has to go into master, 3.6
> and 2.7, three PRs have to be opened?
>

Yes.


>
> (and what do you mean with "when you have a clone available"?)
>

Have a git checkout locally.


>
> > While this doesn?t solve all testing scenarios (e.g. this doesn?t test a
> > macOS or Windows-related change due to the added hours it take for a PR
> > to be ?green? when run on Travis for macOS or AppVeyor for Windows),
>
> In my experience, build times on AppVeyor have recently become more
> competitive with Travis-CI (though mostly because Travis-CI seems to
> have become slower).  However, AppVeyor doesn't seem to schedule several
> build configurations in parallel, so this is best used as a smoke test
> with a single build configuration (also, the test suite could be run in
> a less thorough mode).
>

If someone wants to submit a PR to add a config and see how long it takes
we can always experiment.


>
>
> Thanks for all the work!
>

Welcome!

-Brett


>
> Regards
>
> Antoine.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170211/86588091/attachment.html>

From p.f.moore at gmail.com  Sat Feb 11 04:08:46 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 11 Feb 2017 09:08:46 +0000
Subject: [python-committers] We are now live on GitHub!
In-Reply-To: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
Message-ID: <CACac1F-VcppL9N=vfss5EJ8bgCtF0bUwVfPcOWA1Dqtv1cT2xg@mail.gmail.com>

On 10 February 2017 at 23:19, Brett Cannon <brett at python.org> wrote:
> After more than two years, our new GitHub workflow is ready to accept
> changes

This has been an immense amount of work, looking at the description of
the changes - thanks to everyone who's worked on this but particularly
to Brett for leading it through.

Paul

From barry at python.org  Sat Feb 11 08:50:56 2017
From: barry at python.org (Barry Warsaw)
Date: Sat, 11 Feb 2017 08:50:56 -0500
Subject: [python-committers] We are now live on GitHub!
In-Reply-To: <CACac1F-VcppL9N=vfss5EJ8bgCtF0bUwVfPcOWA1Dqtv1cT2xg@mail.gmail.com>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
 <CACac1F-VcppL9N=vfss5EJ8bgCtF0bUwVfPcOWA1Dqtv1cT2xg@mail.gmail.com>
Message-ID: <20170211085056.489c6681.barry@wooz.org>

On Feb 11, 2017, at 09:08 AM, Paul Moore wrote:

>This has been an immense amount of work, looking at the description of
>the changes - thanks to everyone who's worked on this but particularly
>to Brett for leading it through.

Here, here!  It took an incredible amount of perseverance, dedication, and
leadership to bring this to fruition.  Thanks to Brett for leading the way,
and also to everyone in the Python community who helped us get there.  It's
efforts like this that reinforce to me why the Python community is the best.

-Barry


From guido at python.org  Sat Feb 11 13:14:56 2017
From: guido at python.org (Guido van Rossum)
Date: Sat, 11 Feb 2017 10:14:56 -0800
Subject: [python-committers] We are now live on GitHub!
In-Reply-To: <20170211085056.489c6681.barry@wooz.org>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
 <CACac1F-VcppL9N=vfss5EJ8bgCtF0bUwVfPcOWA1Dqtv1cT2xg@mail.gmail.com>
 <20170211085056.489c6681.barry@wooz.org>
Message-ID: <CAP7+vJ+s4GRwjx==9KV0bOt44PjBmePrE+9LBE_ctD-8aox+FQ@mail.gmail.com>

On Sat, Feb 11, 2017 at 5:50 AM, Barry Warsaw <barry at python.org> wrote:

> On Feb 11, 2017, at 09:08 AM, Paul Moore wrote:
>
> >This has been an immense amount of work, looking at the description of
> >the changes - thanks to everyone who's worked on this but particularly
> >to Brett for leading it through.
>
> Here, here!  It took an incredible amount of perseverance, dedication, and
> leadership to bring this to fruition.  Thanks to Brett for leading the way,
> and also to everyone in the Python community who helped us get there.  It's
> efforts like this that reinforce to me why the Python community is the
> best.
>

+1. Brett, you're the best. And thanks to everyone who helped out!

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170211/fc337e95/attachment.html>

From p.f.moore at gmail.com  Sun Feb 12 06:46:08 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 12 Feb 2017 11:46:08 +0000
Subject: [python-committers] We are now live on GitHub!
In-Reply-To: <CACac1F-VcppL9N=vfss5EJ8bgCtF0bUwVfPcOWA1Dqtv1cT2xg@mail.gmail.com>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
 <CACac1F-VcppL9N=vfss5EJ8bgCtF0bUwVfPcOWA1Dqtv1cT2xg@mail.gmail.com>
Message-ID: <CACac1F-1DXVZTPdD_ng8yjtgPj__L6SQhhVCAscgUsNrWwatqQ@mail.gmail.com>

On 11 February 2017 at 09:08, Paul Moore <p.f.moore at gmail.com> wrote:
> On 10 February 2017 at 23:19, Brett Cannon <brett at python.org> wrote:
>> After more than two years, our new GitHub workflow is ready to accept
>> changes
>
> This has been an immense amount of work, looking at the description of
> the changes - thanks to everyone who's worked on this but particularly
> to Brett for leading it through.

... and just a further note that I'm finding the new github PR
messages much easier to follow than the old python-checkins traffic.
That's probably nothing more than personal familiarity with github,
but nevertheless, even after only a couple of days, the new workflow
is showing benefits for me. So thanks again!

Paul

From storchaka+cpython at gmail.com  Sun Feb 12 07:25:43 2017
From: storchaka+cpython at gmail.com (Serhiy Storchaka)
Date: Sun, 12 Feb 2017 14:25:43 +0200
Subject: [python-committers] The new github PR messages
In-Reply-To: <CACac1F-1DXVZTPdD_ng8yjtgPj__L6SQhhVCAscgUsNrWwatqQ@mail.gmail.com>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
 <CACac1F-VcppL9N=vfss5EJ8bgCtF0bUwVfPcOWA1Dqtv1cT2xg@mail.gmail.com>
 <CACac1F-1DXVZTPdD_ng8yjtgPj__L6SQhhVCAscgUsNrWwatqQ@mail.gmail.com>
Message-ID: <3802605.qblb8t4Kxy@raxxla>

??????, 12 ?????? 2017 ?. 11:46:08 EET Paul Moore ????????:
> ... and just a further note that I'm finding the new github PR
> messages much easier to follow than the old python-checkins traffic.
> That's probably nothing more than personal familiarity with github,
> but nevertheless, even after only a couple of days, the new workflow
> is showing benefits for me. So thanks again!

In contrary, I'm finding the new github PR messages less useful than old 
messages.

1. The subject now starts with longer common prefix. It contains constant 
"[python/cpython]" rather then shorter "cpython" and a part of the hash which 
is less useful for reader (and in any case is duplicated in the message body).

2. The subject no longer contains information about a branch and merge status.

3. The sender name is GitHub rather than the name of committer.

4. The body doesn't contain full diff. It was easier to look at inlined patch 
in mail/news client rather than open separate window in browser.

Is this configurable? I would prefer restoring the old format.


From berker.peksag at gmail.com  Sun Feb 12 07:32:15 2017
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Sun, 12 Feb 2017 15:32:15 +0300
Subject: [python-committers] The new github PR messages
In-Reply-To: <3802605.qblb8t4Kxy@raxxla>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
 <CACac1F-VcppL9N=vfss5EJ8bgCtF0bUwVfPcOWA1Dqtv1cT2xg@mail.gmail.com>
 <CACac1F-1DXVZTPdD_ng8yjtgPj__L6SQhhVCAscgUsNrWwatqQ@mail.gmail.com>
 <3802605.qblb8t4Kxy@raxxla>
Message-ID: <CAF4280L8ijCg6xVyQEBVeqOjPUOucFWuEfdhBcebHgWDqu+xnw@mail.gmail.com>

On Sun, Feb 12, 2017 at 3:25 PM, Serhiy Storchaka
<storchaka+cpython at gmail.com> wrote:
> ??????, 12 ?????? 2017 ?. 11:46:08 EET Paul Moore ????????:
>> ... and just a further note that I'm finding the new github PR
>> messages much easier to follow than the old python-checkins traffic.
>> That's probably nothing more than personal familiarity with github,
>> but nevertheless, even after only a couple of days, the new workflow
>> is showing benefits for me. So thanks again!
>
> In contrary, I'm finding the new github PR messages less useful than old
> messages.
>
> 1. The subject now starts with longer common prefix. It contains constant
> "[python/cpython]" rather then shorter "cpython" and a part of the hash which
> is less useful for reader (and in any case is duplicated in the message body).
>
> 2. The subject no longer contains information about a branch and merge status.
>
> 3. The sender name is GitHub rather than the name of committer.

I haven't tried yet, but I think it's possible to fix this too.

> 4. The body doesn't contain full diff. It was easier to look at inlined patch
> in mail/news client rather than open separate window in browser.
>
> Is this configurable? I would prefer restoring the old format.

I wrote a webhook to restore the old format:
https://github.com/berkerpeksag/cpython-emailer-webhook

You can see the output at
https://github.com/python/core-workflow/issues/24#issuecomment-279162079
and the full discussion at
https://github.com/python/core-workflow/issues/24

--Berker

From mal at egenix.com  Sun Feb 12 07:49:52 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun, 12 Feb 2017 13:49:52 +0100
Subject: [python-committers] The new github PR messages
In-Reply-To: <CAF4280L8ijCg6xVyQEBVeqOjPUOucFWuEfdhBcebHgWDqu+xnw@mail.gmail.com>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
 <CACac1F-VcppL9N=vfss5EJ8bgCtF0bUwVfPcOWA1Dqtv1cT2xg@mail.gmail.com>
 <CACac1F-1DXVZTPdD_ng8yjtgPj__L6SQhhVCAscgUsNrWwatqQ@mail.gmail.com>
 <3802605.qblb8t4Kxy@raxxla>
 <CAF4280L8ijCg6xVyQEBVeqOjPUOucFWuEfdhBcebHgWDqu+xnw@mail.gmail.com>
Message-ID: <8cd678ce-7025-52ce-29f6-c0ea130ecb21@egenix.com>

Related to this: is there a way to unsubcribe from the codecov
notifications ?

Those seem to originate directly from github (rather than being
sent via the checkins list) and so far I've only found the
option to unfollow the entire repo, which is not what I want.

I've installed a filter now, so it's not urgent, but I do
find those messages distracting from the more important
discussion entries of PRs.

Thanks.

On 12.02.2017 13:32, Berker Peksa? wrote:
> On Sun, Feb 12, 2017 at 3:25 PM, Serhiy Storchaka
> <storchaka+cpython at gmail.com> wrote:
>> ??????, 12 ?????? 2017 ?. 11:46:08 EET Paul Moore ????????:
>>> ... and just a further note that I'm finding the new github PR
>>> messages much easier to follow than the old python-checkins traffic.
>>> That's probably nothing more than personal familiarity with github,
>>> but nevertheless, even after only a couple of days, the new workflow
>>> is showing benefits for me. So thanks again!
>>
>> In contrary, I'm finding the new github PR messages less useful than old
>> messages.
>>
>> 1. The subject now starts with longer common prefix. It contains constant
>> "[python/cpython]" rather then shorter "cpython" and a part of the hash which
>> is less useful for reader (and in any case is duplicated in the message body).
>>
>> 2. The subject no longer contains information about a branch and merge status.
>>
>> 3. The sender name is GitHub rather than the name of committer.
> 
> I haven't tried yet, but I think it's possible to fix this too.
> 
>> 4. The body doesn't contain full diff. It was easier to look at inlined patch
>> in mail/news client rather than open separate window in browser.
>>
>> Is this configurable? I would prefer restoring the old format.
> 
> I wrote a webhook to restore the old format:
> https://github.com/berkerpeksag/cpython-emailer-webhook
> 
> You can see the output at
> https://github.com/python/core-workflow/issues/24#issuecomment-279162079
> and the full discussion at
> https://github.com/python/core-workflow/issues/24
> 
> --Berker
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 12 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/


From antoine at python.org  Sun Feb 12 08:33:26 2017
From: antoine at python.org (Antoine Pitrou)
Date: Sun, 12 Feb 2017 14:33:26 +0100
Subject: [python-committers] The new github PR messages
In-Reply-To: <3802605.qblb8t4Kxy@raxxla>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
 <CACac1F-VcppL9N=vfss5EJ8bgCtF0bUwVfPcOWA1Dqtv1cT2xg@mail.gmail.com>
 <CACac1F-1DXVZTPdD_ng8yjtgPj__L6SQhhVCAscgUsNrWwatqQ@mail.gmail.com>
 <3802605.qblb8t4Kxy@raxxla>
Message-ID: <8d060c27-0fb9-1d23-f303-4866ca063d11@python.org>


Le 12/02/2017 ? 13:25, Serhiy Storchaka a ?crit :
> 
> In contrary, I'm finding the new github PR messages less useful than old 
> messages. [...]

I'm a bit surprised: is there a message on python-checkins for each PR
changeset, or only a single one when the PR is squashed+merged?

Regards

Antoine.

From brett at python.org  Sun Feb 12 12:35:16 2017
From: brett at python.org (Brett Cannon)
Date: Sun, 12 Feb 2017 17:35:16 +0000
Subject: [python-committers] We are now live on GitHub!
In-Reply-To: <CACac1F-1DXVZTPdD_ng8yjtgPj__L6SQhhVCAscgUsNrWwatqQ@mail.gmail.com>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
 <CACac1F-VcppL9N=vfss5EJ8bgCtF0bUwVfPcOWA1Dqtv1cT2xg@mail.gmail.com>
 <CACac1F-1DXVZTPdD_ng8yjtgPj__L6SQhhVCAscgUsNrWwatqQ@mail.gmail.com>
Message-ID: <CAP1=2W56sTh2riwVORXq7kT-e6CsXExWdEZ0t9py8U6j0J=5SQ@mail.gmail.com>

On Sun, 12 Feb 2017 at 03:46 Paul Moore <p.f.moore at gmail.com> wrote:

> On 11 February 2017 at 09:08, Paul Moore <p.f.moore at gmail.com> wrote:
> > On 10 February 2017 at 23:19, Brett Cannon <brett at python.org> wrote:
> >> After more than two years, our new GitHub workflow is ready to accept
> >> changes
> >
> > This has been an immense amount of work, looking at the description of
> > the changes - thanks to everyone who's worked on this but particularly
> > to Brett for leading it through.
>
> ... and just a further note that I'm finding the new github PR
> messages much easier to follow than the old python-checkins traffic.
> That's probably nothing more than personal familiarity with github,
> but nevertheless, even after only a couple of days, the new workflow
> is showing benefits for me. So thanks again!
>

Great!

I do plan to check in with everyone after a month or so to see if there are
any obvious sticking points we should consider tweaking, but I want to wait
until we have real-world usage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170212/b6b3e1a5/attachment.html>

From brett at python.org  Sun Feb 12 12:47:05 2017
From: brett at python.org (Brett Cannon)
Date: Sun, 12 Feb 2017 17:47:05 +0000
Subject: [python-committers] The new github PR messages
In-Reply-To: <3802605.qblb8t4Kxy@raxxla>
References: <CAP1=2W6Z-gj9hVVKnqGJNXHB-_ijz1-QumyY30ynmb_5CZ8Psw@mail.gmail.com>
 <CACac1F-VcppL9N=vfss5EJ8bgCtF0bUwVfPcOWA1Dqtv1cT2xg@mail.gmail.com>
 <CACac1F-1DXVZTPdD_ng8yjtgPj__L6SQhhVCAscgUsNrWwatqQ@mail.gmail.com>
 <3802605.qblb8t4Kxy@raxxla>
Message-ID: <CAP1=2W4Fgd7pgUztFDF0rHioJUutpBcjST+8RsjGaHkqPuVP=A@mail.gmail.com>

On Sun, 12 Feb 2017 at 04:26 Serhiy Storchaka <storchaka+cpython at gmail.com>
wrote:

> ??????, 12 ?????? 2017 ?. 11:46:08 EET Paul Moore ????????:
> > ... and just a further note that I'm finding the new github PR
> > messages much easier to follow than the old python-checkins traffic.
> > That's probably nothing more than personal familiarity with github,
> > but nevertheless, even after only a couple of days, the new workflow
> > is showing benefits for me. So thanks again!
>
> In contrary, I'm finding the new github PR messages less useful than old
> messages.
>
> 1. The subject now starts with longer common prefix. It contains constant
> "[python/cpython]" rather then shorter "cpython" and a part of the hash
> which
> is less useful for reader (and in any case is duplicated in the message
> body).
>
> 2. The subject no longer contains information about a branch and merge
> status.
>
> 3. The sender name is GitHub rather than the name of committer.
>
> 4. The body doesn't contain full diff. It was easier to look at inlined
> patch
> in mail/news client rather than open separate window in browser.
>
> Is this configurable? I would prefer restoring the old format.
>

The GitHub service we are using isn't configurable. If you can find an
appropriate integration or service at https://github.com/integrations then
we could consider swapping the services.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170212/af174e32/attachment.html>

From victor.stinner at gmail.com  Sun Feb 12 16:59:07 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sun, 12 Feb 2017 22:59:07 +0100
Subject: [python-committers] New Roundup notifications on Git commits?
Message-ID: <CAMpsgwbzA79tC9oREP9rmxtxJBOWrgKezWSnT2ESBg6vbO0C6A@mail.gmail.com>

Hi,

I merged my pull request:
https://github.com/python/cpython/pull/12

which has a commit message starting with "bpo-29524: ", but the issue
wasn't updated (no new comment to mention the comit):
http://bugs.python.org/issue29524

The final commit is:
https://github.com/python/cpython/commit/c22bfaae83ab5436d008ac0d13e7b47cbe776f08

Is it a known issue? Should I mention the issue number differently?

Victor

From mal at egenix.com  Mon Feb 13 04:33:58 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 13 Feb 2017 10:33:58 +0100
Subject: [python-committers] Discussions on PRs
Message-ID: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>

With the move to Github, I'm seeing a move away from
discussions on the issue tracker towards discussions on
pull requests.

Example: https://github.com/python/cpython/pull/4

Is this something we should encourage or better ask the OPs
to open a ticket on the tracker first and reference the PR
there ?

Discussion on the PRs would then only be for code review
aspects.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 13 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/


From victor.stinner at gmail.com  Mon Feb 13 04:48:52 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 13 Feb 2017 10:48:52 +0100
Subject: [python-committers] Discussions on PRs
In-Reply-To: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
References: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
Message-ID: <CAMpsgwaB53XVahwwyFa5PHt=F4YG0oJven93xMC9-OTBcYfyEw@mail.gmail.com>

I prefer to discuss on the review rather than on the bug tracker. In
the extreme case, if we had to choose, I had rather prefer to drop the
bug tracker. It is not going to appear since people still have to
report bugs without patch :-)

Victor

2017-02-13 10:33 GMT+01:00 M.-A. Lemburg <mal at egenix.com>:
> With the move to Github, I'm seeing a move away from
> discussions on the issue tracker towards discussions on
> pull requests.
>
> Example: https://github.com/python/cpython/pull/4
>
> Is this something we should encourage or better ask the OPs
> to open a ticket on the tracker first and reference the PR
> there ?
>
> Discussion on the PRs would then only be for code review
> aspects.
>
> Thanks,
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Feb 13 2017)
>>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>>> Python Database Interfaces ...           http://products.egenix.com/
>>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
> ________________________________________________________________________
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>            Registered at Amtsgericht Duesseldorf: HRB 46611
>                http://www.egenix.com/company/contact/
>                       http://www.malemburg.com/
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

From stefan at bytereef.org  Mon Feb 13 05:49:25 2017
From: stefan at bytereef.org (Stefan Krah)
Date: Mon, 13 Feb 2017 11:49:25 +0100
Subject: [python-committers] Discussions on PRs
In-Reply-To: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
References: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
Message-ID: <20170213104925.GA2764@bytereef.org>


On Mon, Feb 13, 2017 at 10:33:58AM +0100, M.-A. Lemburg wrote:
> With the move to Github, I'm seeing a move away from
> discussions on the issue tracker towards discussions on
> pull requests.
> 
> Example: https://github.com/python/cpython/pull/4
> 
> Is this something we should encourage or better ask the OPs
> to open a ticket on the tracker first and reference the PR
> there ?
> 
> Discussion on the PRs would then only be for code review
> aspects.

I agree completely.  I find the whole workflow very distracting.  What I
see now is that patches without comments emerge really fast:

    https://github.com/python/cpython/pull/65


Actually I expected this competitive atmosphere, because that's what
GitHub encourages.

Realistically, my workload tripled for this one particular issue
compared to our previous workflow.



Stefan Krah





From donald at stufft.io  Mon Feb 13 08:48:08 2017
From: donald at stufft.io (Donald Stufft)
Date: Mon, 13 Feb 2017 08:48:08 -0500
Subject: [python-committers] Discussions on PRs
In-Reply-To: <20170213104925.GA2764@bytereef.org>
References: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
 <20170213104925.GA2764@bytereef.org>
Message-ID: <ED303F10-5CE6-4B4F-8023-867C97386E53@stufft.io>


> On Feb 13, 2017, at 5:49 AM, Stefan Krah <stefan at bytereef.org> wrote:
> 
> What I
> see now is that patches without comments emerge really fast:
> 
>    https://github.com/python/cpython/pull/65 <https://github.com/python/cpython/pull/65>


It looks like the person in question is commenting on the issue tracker.

?
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170213/2fb54eee/attachment.html>

From stefan at bytereef.org  Mon Feb 13 08:59:11 2017
From: stefan at bytereef.org (Stefan Krah)
Date: Mon, 13 Feb 2017 14:59:11 +0100
Subject: [python-committers] Discussions on PRs
In-Reply-To: <ED303F10-5CE6-4B4F-8023-867C97386E53@stufft.io>
References: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
 <20170213104925.GA2764@bytereef.org>
 <ED303F10-5CE6-4B4F-8023-867C97386E53@stufft.io>
Message-ID: <20170213135910.GA3155@bytereef.org>



On Mon, Feb 13, 2017 at 08:48:08AM -0500, Donald Stufft wrote:
> It looks like the person in question is commenting on the issue tracker.

Is *now* commenting on the issue tracker as opposed to when I wrote the
mail.  But hey, it sounds much more impressive the way you phrased it ...


Stefan




From victor.stinner at gmail.com  Mon Feb 13 09:49:33 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 13 Feb 2017 15:49:33 +0100
Subject: [python-committers] Disable Codecov on GitHub pull requests?
Message-ID: <CAMpsgwbaQOn0+AqCH=1iiU+AeBfzQ=pobR2hfW8VNmEpbF7sww@mail.gmail.com>

Hi,

I don't get the value of code coverage on a CI. I *like* running code
coverage sometimes, but I don't like being annoying by "test failed:
coverage -0,01%" by a change completely unrelated to code (note: this
issue has been fixed be using a threshold of 1%). I'm annoyed by all
these Codecov messages. Berker just told me that he even created a
Gmail filter to drop all these email notifications...

What do you think of keeping this very useful feature, but not use it
on pull requests: only run it on the branches (once changes are
merged), to not "pollute" pull requests?

Victor

From alex.gaynor at gmail.com  Mon Feb 13 09:51:47 2017
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Mon, 13 Feb 2017 09:51:47 -0500
Subject: [python-committers] Disable Codecov on GitHub pull requests?
In-Reply-To: <CAMpsgwbaQOn0+AqCH=1iiU+AeBfzQ=pobR2hfW8VNmEpbF7sww@mail.gmail.com>
References: <CAMpsgwbaQOn0+AqCH=1iiU+AeBfzQ=pobR2hfW8VNmEpbF7sww@mail.gmail.com>
Message-ID: <CAFRnB2U_qSjvbprOCe=6_Cg1uSjHA9FR3eh-wiwCkDPC4vSdqQ@mail.gmail.com>

I'm obviously not very active in CPython development these days, but
actively tracking the impact of each PR on coverage has been extremely
useful in every other project I've worked on.

It's the best way to automatically ensure PRs are not regressing coverage
too much, and doesn't require much manual work. FWIW, on projects I've
worked on we have turned off the codecov "comments", and instead just rely
on the status checker.

Alex

On Mon, Feb 13, 2017 at 9:49 AM, Victor Stinner <victor.stinner at gmail.com>
wrote:

> Hi,
>
> I don't get the value of code coverage on a CI. I *like* running code
> coverage sometimes, but I don't like being annoying by "test failed:
> coverage -0,01%" by a change completely unrelated to code (note: this
> issue has been fixed be using a threshold of 1%). I'm annoyed by all
> these Codecov messages. Berker just told me that he even created a
> Gmail filter to drop all these email notifications...
>
> What do you think of keeping this very useful feature, but not use it
> on pull requests: only run it on the branches (once changes are
> merged), to not "pollute" pull requests?
>
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170213/1a94565c/attachment-0001.html>

From donald at stufft.io  Mon Feb 13 10:04:43 2017
From: donald at stufft.io (Donald Stufft)
Date: Mon, 13 Feb 2017 10:04:43 -0500
Subject: [python-committers] Disable Codecov on GitHub pull requests?
In-Reply-To: <CAMpsgwbaQOn0+AqCH=1iiU+AeBfzQ=pobR2hfW8VNmEpbF7sww@mail.gmail.com>
References: <CAMpsgwbaQOn0+AqCH=1iiU+AeBfzQ=pobR2hfW8VNmEpbF7sww@mail.gmail.com>
Message-ID: <5F51277A-3EBE-4290-91EC-8A4FD1527EBF@stufft.io>


> On Feb 13, 2017, at 9:49 AM, Victor Stinner <victor.stinner at gmail.com> wrote:
> 
> Hi,
> 
> I don't get the value of code coverage on a CI. I *like* running code
> coverage sometimes, but I don't like being annoying by "test failed:
> coverage -0,01%" by a change completely unrelated to code (note: this
> issue has been fixed be using a threshold of 1%). I'm annoyed by all
> these Codecov messages. Berker just told me that he even created a
> Gmail filter to drop all these email notifications...
> 
> What do you think of keeping this very useful feature, but not use it
> on pull requests: only run it on the branches (once changes are
> merged), to not "pollute" pull requests?
> 


I think it?s incredibly useful on PRs, particularly because it can tell you if the PR has actually covered every line that it?s added or not. If you?re only periodically running coverage, then in my experience you generally miss covering a lot of lines accidentally. I?ve also never see the random -0.01% coverage of code in another project, and my guess is that there is some sort of non-determinism in the CPython test suite that would be a good idea to make deterministic anyways.

As with Alex, most projects I?ve been involved in turn off the comments and rely on the status checker.


?
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170213/0ab9f030/attachment.html>

From barry at python.org  Mon Feb 13 10:08:26 2017
From: barry at python.org (Barry Warsaw)
Date: Mon, 13 Feb 2017 10:08:26 -0500
Subject: [python-committers] Disable Codecov on GitHub pull requests?
In-Reply-To: <CAFRnB2U_qSjvbprOCe=6_Cg1uSjHA9FR3eh-wiwCkDPC4vSdqQ@mail.gmail.com>
References: <CAMpsgwbaQOn0+AqCH=1iiU+AeBfzQ=pobR2hfW8VNmEpbF7sww@mail.gmail.com>
 <CAFRnB2U_qSjvbprOCe=6_Cg1uSjHA9FR3eh-wiwCkDPC4vSdqQ@mail.gmail.com>
Message-ID: <20170213100826.46324537@subdivisions.wooz.org>

On Feb 13, 2017, at 09:51 AM, Alex Gaynor wrote:

>actively tracking the impact of each PR on coverage has been extremely
>useful in every other project I've worked on.

Agreed.

>FWIW, on projects I've worked on we have turned off the codecov "comments",
>and instead just rely on the status checker.

Also agreed.  On many projects we do two things, both of which are usually
implemented as status checks without the coverage comments.  We use coverage
to enforce a ratchet so coverage doesn't regress (assuming a stable test
suite), and we use diffcov to ensure that any new code being proposed is 100%
covered.

Another useful tool that doesn't exist yet, though there were some
conversations about it at a previous Pycon is a tool that ensures that a test
for the new code has been added.  It would do this by running the test suite
without the (non-test-suite) change and proving that the test failed, then
reapply the fix and prove that the test suite passed.  It's unfortunately not
uncommon for someone to submit a PR with a test that they *think* tests the
new code but actually doesn't, and the only way to check that now is locally
and manually.

https://github.com/paulcollinsiii/hasregression

+1 for suppressing the coverage comments.

Cheers,
-Barry

From barry at python.org  Mon Feb 13 10:12:41 2017
From: barry at python.org (Barry Warsaw)
Date: Mon, 13 Feb 2017 10:12:41 -0500
Subject: [python-committers] Discussions on PRs
In-Reply-To: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
References: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
Message-ID: <20170213101241.7d160157@subdivisions.wooz.org>

On Feb 13, 2017, at 10:33 AM, M.-A. Lemburg wrote:

>Discussion on the PRs would then only be for code review
>aspects.

+1

On Feb 13, 2017, at 11:49 AM, Stefan Krah wrote:

>Realistically, my workload tripled for this one particular issue
>compared to our previous workflow.

Not to mention the size of my inbox. :(

Cheers,
-Barry

From victor.stinner at gmail.com  Mon Feb 13 10:25:43 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 13 Feb 2017 16:25:43 +0100
Subject: [python-committers] Disable Codecov on GitHub pull requests?
In-Reply-To: <5F51277A-3EBE-4290-91EC-8A4FD1527EBF@stufft.io>
References: <CAMpsgwbaQOn0+AqCH=1iiU+AeBfzQ=pobR2hfW8VNmEpbF7sww@mail.gmail.com>
 <5F51277A-3EBE-4290-91EC-8A4FD1527EBF@stufft.io>
Message-ID: <CAMpsgwYxh_CsZ_LSpnhUnr_Ye-3q3zyxeTpiULWfTPYvagU0YA@mail.gmail.com>

2017-02-13 16:04 GMT+01:00 Donald Stufft <donald at stufft.io>:
> I?ve also never see the random -0.01%
> coverage of code in another project, and my guess is that there is some sort
> of non-determinism in the CPython test suite that would be a good idea to
> make deterministic anyways.

Can we hide/disable Codecov notifications until this issue is fixed?
Example of false alarm:
https://github.com/python/cpython/pull/61#issuecomment-279291824
heapq.py coverage -0.77% on a change modifying Doc/library/typing.rst

See also: "Adjust coverage failure threshold"
https://github.com/python/core-workflow/issues/21

Victor

From brett at python.org  Mon Feb 13 13:11:36 2017
From: brett at python.org (Brett Cannon)
Date: Mon, 13 Feb 2017 18:11:36 +0000
Subject: [python-committers] Disable Codecov on GitHub pull requests?
In-Reply-To: <CAMpsgwYxh_CsZ_LSpnhUnr_Ye-3q3zyxeTpiULWfTPYvagU0YA@mail.gmail.com>
References: <CAMpsgwbaQOn0+AqCH=1iiU+AeBfzQ=pobR2hfW8VNmEpbF7sww@mail.gmail.com>
 <5F51277A-3EBE-4290-91EC-8A4FD1527EBF@stufft.io>
 <CAMpsgwYxh_CsZ_LSpnhUnr_Ye-3q3zyxeTpiULWfTPYvagU0YA@mail.gmail.com>
Message-ID: <CAP1=2W5Eh4urprbxP+H-+M1ooQNdQv1D3Kw1BfsePX91pD_SkA@mail.gmail.com>

On Mon, 13 Feb 2017 at 07:26 Victor Stinner <victor.stinner at gmail.com>
wrote:

> 2017-02-13 16:04 GMT+01:00 Donald Stufft <donald at stufft.io>:
> > I?ve also never see the random -0.01%
> > coverage of code in another project, and my guess is that there is some
> sort
> > of non-determinism in the CPython test suite that would be a good idea to
> > make deterministic anyways.
>
> Can we hide/disable Codecov notifications until this issue is fixed?
> Example of false alarm:
> https://github.com/python/cpython/pull/61#issuecomment-279291824
> heapq.py coverage -0.77% on a change modifying Doc/library/typing.rst
>
> See also: "Adjust coverage failure threshold"
> https://github.com/python/core-workflow/issues/21


Codecov's configuration is controlled by
https://github.com/python/cpython/blob/master/.codecov.yml so you can
submit a PR to propose changes to how coverage is reported. Docs can be
found at https://docs.codecov.io/docs/codecov-yaml .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170213/d1500da2/attachment.html>

From brett at python.org  Mon Feb 13 13:16:35 2017
From: brett at python.org (Brett Cannon)
Date: Mon, 13 Feb 2017 18:16:35 +0000
Subject: [python-committers] New Roundup notifications on Git commits?
In-Reply-To: <CAMpsgwbzA79tC9oREP9rmxtxJBOWrgKezWSnT2ESBg6vbO0C6A@mail.gmail.com>
References: <CAMpsgwbzA79tC9oREP9rmxtxJBOWrgKezWSnT2ESBg6vbO0C6A@mail.gmail.com>
Message-ID: <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>

There was an issue up until sometime on Sunday where the SSL cert for
bugs.python.org was being rejected (it was issued by StartCom who is being
distrusted). The cert got replaced but if the webhook event for your merge
got rejected due to the bad cert then it would have been dropped.

So if should be working, but you may have been caught in the SSL problem.
If it persists then there's a problem in the hook-side of bugs.python.org
that will need fixing.

On Sun, 12 Feb 2017 at 13:59 Victor Stinner <victor.stinner at gmail.com>
wrote:

> Hi,
>
> I merged my pull request:
> https://github.com/python/cpython/pull/12
>
> which has a commit message starting with "bpo-29524: ", but the issue
> wasn't updated (no new comment to mention the comit):
> http://bugs.python.org/issue29524
>
> The final commit is:
>
> https://github.com/python/cpython/commit/c22bfaae83ab5436d008ac0d13e7b47cbe776f08
>
> Is it a known issue? Should I mention the issue number differently?
>
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170213/2001e09a/attachment.html>

From brian at python.org  Mon Feb 13 13:17:14 2017
From: brian at python.org (Brian Curtin)
Date: Mon, 13 Feb 2017 13:17:14 -0500
Subject: [python-committers] Disable Codecov on GitHub pull requests?
In-Reply-To: <CAP1=2W5Eh4urprbxP+H-+M1ooQNdQv1D3Kw1BfsePX91pD_SkA@mail.gmail.com>
References: <CAMpsgwbaQOn0+AqCH=1iiU+AeBfzQ=pobR2hfW8VNmEpbF7sww@mail.gmail.com>
 <5F51277A-3EBE-4290-91EC-8A4FD1527EBF@stufft.io>
 <CAMpsgwYxh_CsZ_LSpnhUnr_Ye-3q3zyxeTpiULWfTPYvagU0YA@mail.gmail.com>
 <CAP1=2W5Eh4urprbxP+H-+M1ooQNdQv1D3Kw1BfsePX91pD_SkA@mail.gmail.com>
Message-ID: <CAD+XWwpnqyWF069bupDFzQUvyiXFF7aRjqKS8tRjnEKPj1b0sQ@mail.gmail.com>

On Mon, Feb 13, 2017 at 1:11 PM, Brett Cannon <brett at python.org> wrote:
>
>
> On Mon, 13 Feb 2017 at 07:26 Victor Stinner <victor.stinner at gmail.com>
> wrote:
>>
>> 2017-02-13 16:04 GMT+01:00 Donald Stufft <donald at stufft.io>:
>> > I?ve also never see the random -0.01%
>> > coverage of code in another project, and my guess is that there is some
>> > sort
>> > of non-determinism in the CPython test suite that would be a good idea
>> > to
>> > make deterministic anyways.
>>
>> Can we hide/disable Codecov notifications until this issue is fixed?
>> Example of false alarm:
>> https://github.com/python/cpython/pull/61#issuecomment-279291824
>> heapq.py coverage -0.77% on a change modifying Doc/library/typing.rst
>>
>> See also: "Adjust coverage failure threshold"
>> https://github.com/python/core-workflow/issues/21
>
>
> Codecov's configuration is controlled by
> https://github.com/python/cpython/blob/master/.codecov.yml so you can submit
> a PR to propose changes to how coverage is reported. Docs can be found at
> https://docs.codecov.io/docs/codecov-yaml .

Berker has https://github.com/python/cpython/pull/71 up right now. I
think it looks ok so far from what I understand.

From berker.peksag at gmail.com  Mon Feb 13 13:14:54 2017
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Mon, 13 Feb 2017 21:14:54 +0300
Subject: [python-committers] Disable Codecov on GitHub pull requests?
In-Reply-To: <CAMpsgwYxh_CsZ_LSpnhUnr_Ye-3q3zyxeTpiULWfTPYvagU0YA@mail.gmail.com>
References: <CAMpsgwbaQOn0+AqCH=1iiU+AeBfzQ=pobR2hfW8VNmEpbF7sww@mail.gmail.com>
 <5F51277A-3EBE-4290-91EC-8A4FD1527EBF@stufft.io>
 <CAMpsgwYxh_CsZ_LSpnhUnr_Ye-3q3zyxeTpiULWfTPYvagU0YA@mail.gmail.com>
Message-ID: <CAF4280+3cC8MBAwrKHjiMdicZPdrwOSLgitdchm7zUw95q-BRA@mail.gmail.com>

On Mon, Feb 13, 2017 at 6:25 PM, Victor Stinner
<victor.stinner at gmail.com> wrote:
> 2017-02-13 16:04 GMT+01:00 Donald Stufft <donald at stufft.io>:
>> I?ve also never see the random -0.01%
>> coverage of code in another project, and my guess is that there is some sort
>> of non-determinism in the CPython test suite that would be a good idea to
>> make deterministic anyways.
>
> Can we hide/disable Codecov notifications until this issue is fixed?
> Example of false alarm:
> https://github.com/python/cpython/pull/61#issuecomment-279291824
> heapq.py coverage -0.77% on a change modifying Doc/library/typing.rst
>
> See also: "Adjust coverage failure threshold"
> https://github.com/python/core-workflow/issues/21

I've opened to tweak our Codecov configuration:
https://github.com/python/cpython/pull/71

--Berker

From storchaka+cpython at gmail.com  Mon Feb 13 13:30:53 2017
From: storchaka+cpython at gmail.com (Serhiy Storchaka)
Date: Mon, 13 Feb 2017 20:30:53 +0200
Subject: [python-committers] Discussions on PRs
In-Reply-To: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
References: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
Message-ID: <1800743.Nfj3torDxh@raxxla>

?????????, 13 ?????? 2017 ?. 10:33:58 EET M.-A. Lemburg ????????:
> With the move to Github, I'm seeing a move away from
> discussions on the issue tracker towards discussions on
> pull requests.
> 
> Example: https://github.com/python/cpython/pull/4
> 
> Is this something we should encourage or better ask the OPs
> to open a ticket on the tracker first and reference the PR
> there ?
> 
> Discussion on the PRs would then only be for code review
> aspects.

I prefer discussions on the issue tracker. First, it is better to have all 
discussion in one place. Second, I got hundreds of email messages last day and 
discussions interesting by me just are lost in a flame. I'm going to 
unsubscribe from getting emails for all pull requests and subscribe to only 
selected ones.

From victor.stinner at gmail.com  Mon Feb 13 17:49:41 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 13 Feb 2017 23:49:41 +0100
Subject: [python-committers] Discussions on PRs
In-Reply-To: <1800743.Nfj3torDxh@raxxla>
References: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
 <1800743.Nfj3torDxh@raxxla>
Message-ID: <CAMpsgwZe0bTyZS14J7LvhP19hFZsTKV54R_96awrvTAdRpRHdw@mail.gmail.com>

2017-02-13 19:30 GMT+01:00 Serhiy Storchaka <storchaka+cpython at gmail.com>:
> I'm going to
> unsubscribe from getting emails for all pull requests and subscribe to only
> selected ones.

I did exactly that, very early :-)

https://github.com/python/cpython/ : "Watch: *not watching*. Be
notified when participating or @mention".

I never tried to follow *everything* on bugs.python.org, there is too
much trafic ;-)

Victor

From ezio.melotti at gmail.com  Mon Feb 13 18:19:52 2017
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 14 Feb 2017 01:19:52 +0200
Subject: [python-committers] New Roundup notifications on Git commits?
In-Reply-To: <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
References: <CAMpsgwbzA79tC9oREP9rmxtxJBOWrgKezWSnT2ESBg6vbO0C6A@mail.gmail.com>
 <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
Message-ID: <CACBhJdE_AnWfbUE8zA5jsH2GeruS2af=C-+4GjTSDvbrcudxww@mail.gmail.com>

I've been keeping an eye on the tracker logs and saw no errors.  If
you are still having problems after the SSL fix let me know.

On Mon, Feb 13, 2017 at 8:16 PM, Brett Cannon <brett at python.org> wrote:
> There was an issue up until sometime on Sunday where the SSL cert for
> bugs.python.org was being rejected (it was issued by StartCom who is being
> distrusted). The cert got replaced but if the webhook event for your merge
> got rejected due to the bad cert then it would have been dropped.
>
> So if should be working, but you may have been caught in the SSL problem. If
> it persists then there's a problem in the hook-side of bugs.python.org that
> will need fixing.
>
> On Sun, 12 Feb 2017 at 13:59 Victor Stinner <victor.stinner at gmail.com>
> wrote:
>>
>> Hi,
>>
>> I merged my pull request:
>> https://github.com/python/cpython/pull/12
>>
>> which has a commit message starting with "bpo-29524: ", but the issue
>> wasn't updated (no new comment to mention the comit):
>> http://bugs.python.org/issue29524
>>
>> The final commit is:
>>
>> https://github.com/python/cpython/commit/c22bfaae83ab5436d008ac0d13e7b47cbe776f08
>>
>> Is it a known issue? Should I mention the issue number differently?
>>
>> Victor
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

From ezio.melotti at gmail.com  Mon Feb 13 18:25:19 2017
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 14 Feb 2017 01:25:19 +0200
Subject: [python-committers] Discussions on PRs
In-Reply-To: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
References: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
Message-ID: <CACBhJdFrDXhzx2OBzqOA8H10hq7SLDfw2X60pd66an5UvL-FZQ@mail.gmail.com>

On Mon, Feb 13, 2017 at 11:33 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> With the move to Github, I'm seeing a move away from
> discussions on the issue tracker towards discussions on
> pull requests.
>
> Example: https://github.com/python/cpython/pull/4
>
> Is this something we should encourage or better ask the OPs
> to open a ticket on the tracker first and reference the PR
> there ?
>

Unless it's a trivial PR (e.g. typo fix), then there should be a
discussion on bpo.  The devguide has been/is being update to be more
clear about this aspect.

> Discussion on the PRs would then only be for code review
> aspects.
>

Yes, discussions on the PRs replace the discussions we had on Rietveld
-- they should only be about the code review.

Best Regards,
Ezio Melotti

> Thanks,
> --
> Marc-Andre Lemburg
> eGenix.com

From ericsnowcurrently at gmail.com  Mon Feb 13 19:19:44 2017
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Mon, 13 Feb 2017 17:19:44 -0700
Subject: [python-committers] New Roundup notifications on Git commits?
In-Reply-To: <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
References: <CAMpsgwbzA79tC9oREP9rmxtxJBOWrgKezWSnT2ESBg6vbO0C6A@mail.gmail.com>
 <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
Message-ID: <CALFfu7CY5tcmWN1ARBMs8XiLZFUqT_hkGGh=aE7XSLEdrg6=mg@mail.gmail.com>

On Mon, Feb 13, 2017 at 11:16 AM, Brett Cannon <brett at python.org> wrote:
> if the webhook event for your merge
> got rejected due to the bad cert then it would have been dropped.

A repo admin should be able to manually request that a failed webhook
be retried.  The webhook's page on GH has a list of all associated
events, including failed attempts.

-eric

From victor.stinner at gmail.com  Tue Feb 14 12:10:40 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 14 Feb 2017 18:10:40 +0100
Subject: [python-committers] Accept a PR but only push it once tests pass?
Message-ID: <CAMpsgwaGfg-Ry0dyWWO=xBa28mEPNEhvMSDW5hWiRt1yOxKq7Q@mail.gmail.com>

Hi,

Would it be possible to modify the workflow of GitHub pull requests to
allow to click on Merge, but only merge a PR once tests complete and
only if tests pass?

If some tests start to become too annoying for the pre-commit CI, we
can try to fix them, or even disable them in the CI to only rely on
post-commit buildbots.

Victor

From senthil at uthcode.com  Tue Feb 14 12:19:04 2017
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 14 Feb 2017 09:19:04 -0800
Subject: [python-committers] Accept a PR but only push it once tests
 pass?
In-Reply-To: <CAMpsgwaGfg-Ry0dyWWO=xBa28mEPNEhvMSDW5hWiRt1yOxKq7Q@mail.gmail.com>
References: <CAMpsgwaGfg-Ry0dyWWO=xBa28mEPNEhvMSDW5hWiRt1yOxKq7Q@mail.gmail.com>
Message-ID: <CAPOVWOSmG_o92_yzXyVTw+OeMUV4h=w2KEbzYi8EPNvxrETWhQ@mail.gmail.com>

On Tue, Feb 14, 2017 at 9:10 AM, Victor Stinner
<victor.stinner at gmail.com> wrote:
> Would it be possible to modify the workflow of GitHub pull requests to
> allow to click on Merge, but only merge a PR once tests complete and
> only if tests pass?

Yes, that is possible.

I am +1 in doing that. I hope others are on the same page. If in
agreement, I will enable that in github.

It's called "Require status checks to pass before merging" and we can
enable travis-ci to go green before allowing to merge.

Thanks,
Senthil

From brett at python.org  Tue Feb 14 12:36:45 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 14 Feb 2017 17:36:45 +0000
Subject: [python-committers] New Roundup notifications on Git commits?
In-Reply-To: <CALFfu7CY5tcmWN1ARBMs8XiLZFUqT_hkGGh=aE7XSLEdrg6=mg@mail.gmail.com>
References: <CAMpsgwbzA79tC9oREP9rmxtxJBOWrgKezWSnT2ESBg6vbO0C6A@mail.gmail.com>
 <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
 <CALFfu7CY5tcmWN1ARBMs8XiLZFUqT_hkGGh=aE7XSLEdrg6=mg@mail.gmail.com>
Message-ID: <CAP1=2W4KWfhPbATXrmD2kjPMy5bJnSOjJ1Ojhw5xueeXHx=iQw@mail.gmail.com>

On Mon, 13 Feb 2017 at 16:19 Eric Snow <ericsnowcurrently at gmail.com> wrote:

> On Mon, Feb 13, 2017 at 11:16 AM, Brett Cannon <brett at python.org> wrote:
> > if the webhook event for your merge
> > got rejected due to the bad cert then it would have been dropped.
>
> A repo admin should be able to manually request that a failed webhook
> be retried.  The webhook's page on GH has a list of all associated
> events, including failed attempts.
>

Yes, but the sheer volume of events makes doing that extremely tedious.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170214/46642443/attachment.html>

From brett at python.org  Tue Feb 14 12:38:04 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 14 Feb 2017 17:38:04 +0000
Subject: [python-committers] Accept a PR but only push it once tests
 pass?
In-Reply-To: <CAPOVWOSmG_o92_yzXyVTw+OeMUV4h=w2KEbzYi8EPNvxrETWhQ@mail.gmail.com>
References: <CAMpsgwaGfg-Ry0dyWWO=xBa28mEPNEhvMSDW5hWiRt1yOxKq7Q@mail.gmail.com>
 <CAPOVWOSmG_o92_yzXyVTw+OeMUV4h=w2KEbzYi8EPNvxrETWhQ@mail.gmail.com>
Message-ID: <CAP1=2W5c+6gCoyqBW0OH7bSuLiXcd6awFmBj2ho85Tm4vZqH2w@mail.gmail.com>

On Tue, 14 Feb 2017 at 09:19 Senthil Kumaran <senthil at uthcode.com> wrote:

> On Tue, Feb 14, 2017 at 9:10 AM, Victor Stinner
> <victor.stinner at gmail.com> wrote:
> > Would it be possible to modify the workflow of GitHub pull requests to
> > allow to click on Merge, but only merge a PR once tests complete and
> > only if tests pass?
>
> Yes, that is possible.
>
> I am +1 in doing that. I hope others are on the same page. If in
> agreement, I will enable that in github.
>
> It's called "Require status checks to pass before merging" and we can
> enable travis-ci to go green before allowing to merge.
>

The reason I didn't turn that on to begin with was I wanted to wait until
we had proven to ourselves that our test suite was stable enough to not
block PRs on a regular basis due to some flaky test. If people feel the
tests are passing consistently when they should then I'm all for flipping
on this protection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170214/e18130d5/attachment.html>

From victor.stinner at gmail.com  Tue Feb 14 12:56:24 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 14 Feb 2017 18:56:24 +0100
Subject: [python-committers] Accept a PR but only push it once tests
 pass?
In-Reply-To: <CAP1=2W5c+6gCoyqBW0OH7bSuLiXcd6awFmBj2ho85Tm4vZqH2w@mail.gmail.com>
References: <CAMpsgwaGfg-Ry0dyWWO=xBa28mEPNEhvMSDW5hWiRt1yOxKq7Q@mail.gmail.com>
 <CAPOVWOSmG_o92_yzXyVTw+OeMUV4h=w2KEbzYi8EPNvxrETWhQ@mail.gmail.com>
 <CAP1=2W5c+6gCoyqBW0OH7bSuLiXcd6awFmBj2ho85Tm4vZqH2w@mail.gmail.com>
Message-ID: <CAMpsgwYfpEME-fCh1TLKhKUMrVpH87_PfCy1LuM96Jd7h=02CQ@mail.gmail.com>

2017-02-14 18:38 GMT+01:00 Brett Cannon <brett at python.org>:
> The reason I didn't turn that on to begin with was I wanted to wait until we
> had proven to ourselves that our test suite was stable enough to not block
> PRs on a regular basis due to some flaky test. If people feel the tests are
> passing consistently when they should then I'm all for flipping on this
> protection.

Oh ok, I see. Let's say that we wait one month to see how things are
going before changing the process ;-)

Hopefully the Travis CI jobs are currently quite fast: less than 10
minutes, whereas many buildbots take longer than 1 hour! (up to 5
hours in the worst cases)

Victor

From senthil at uthcode.com  Tue Feb 14 13:02:22 2017
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 14 Feb 2017 10:02:22 -0800
Subject: [python-committers] Accept a PR but only push it once tests
 pass?
In-Reply-To: <CAMpsgwYfpEME-fCh1TLKhKUMrVpH87_PfCy1LuM96Jd7h=02CQ@mail.gmail.com>
References: <CAMpsgwaGfg-Ry0dyWWO=xBa28mEPNEhvMSDW5hWiRt1yOxKq7Q@mail.gmail.com>
 <CAPOVWOSmG_o92_yzXyVTw+OeMUV4h=w2KEbzYi8EPNvxrETWhQ@mail.gmail.com>
 <CAP1=2W5c+6gCoyqBW0OH7bSuLiXcd6awFmBj2ho85Tm4vZqH2w@mail.gmail.com>
 <CAMpsgwYfpEME-fCh1TLKhKUMrVpH87_PfCy1LuM96Jd7h=02CQ@mail.gmail.com>
Message-ID: <CAPOVWOQ9jWPebVS0mFz9A7ax7pbbis_D517sBPmHKRrVcL88og@mail.gmail.com>

On Tue, Feb 14, 2017 at 9:56 AM, Victor Stinner
<victor.stinner at gmail.com> wrote:
>
> Oh ok, I see. Let's say that we wait one month to see how things are
> going before changing the process ;-)

I'd say we do it and see if it is worth keep it that way.

- The PR tests are passing and we have an incentive to maintain that.

- The only tests which have a Red mark (failing ci) are not those
whose branches are not rebased against the HEAD of master.  So, if we
make it a requirement, authors will have to rebase their changes on
top origin/master HEAD, and will get accurate test information for
their PR.

-- 
Senthil

From mal at egenix.com  Tue Feb 14 13:16:20 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 14 Feb 2017 19:16:20 +0100
Subject: [python-committers] Discussions on PRs
In-Reply-To: <CAMpsgwZe0bTyZS14J7LvhP19hFZsTKV54R_96awrvTAdRpRHdw@mail.gmail.com>
References: <5daf8f77-2194-a5ab-50fa-2f7beda8ef03@egenix.com>
 <1800743.Nfj3torDxh@raxxla>
 <CAMpsgwZe0bTyZS14J7LvhP19hFZsTKV54R_96awrvTAdRpRHdw@mail.gmail.com>
Message-ID: <31c9745e-f9c5-8535-1db2-ce71c516c0a9@egenix.com>

On 13.02.2017 23:49, Victor Stinner wrote:
> 2017-02-13 19:30 GMT+01:00 Serhiy Storchaka <storchaka+cpython at gmail.com>:
>> I'm going to
>> unsubscribe from getting emails for all pull requests and subscribe to only
>> selected ones.
> 
> I did exactly that, very early :-)
> 
> https://github.com/python/cpython/ : "Watch: *not watching*. Be
> notified when participating or @mention".
> 
> I never tried to follow *everything* on bugs.python.org, there is too
> much trafic ;-)

That's a great idea to focus on bpo discussions again. My Inbox was
exploding in the last few days, even with filters on.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 14 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/


From ezio.melotti at gmail.com  Tue Feb 14 20:08:39 2017
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Wed, 15 Feb 2017 03:08:39 +0200
Subject: [python-committers] New Roundup notifications on Git commits?
In-Reply-To: <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
References: <CAMpsgwbzA79tC9oREP9rmxtxJBOWrgKezWSnT2ESBg6vbO0C6A@mail.gmail.com>
 <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
Message-ID: <CACBhJdG4+6-vOx8bPR_KDFAWWiKckJH5TxnTTp=huUV7rC98oQ@mail.gmail.com>

On Mon, Feb 13, 2017 at 8:16 PM, Brett Cannon <brett at python.org> wrote:
> There was an issue up until sometime on Sunday where the SSL cert for
> bugs.python.org was being rejected (it was issued by StartCom who is being
> distrusted). The cert got replaced but if the webhook event for your merge
> got rejected due to the bad cert then it would have been dropped.
>

Today I also spotted and fixed another issue, and verified that now
the messages are showing up on bpo (see e.g.
http://bugs.python.org/issue29557#msg287801).  Let me know if there
are other issues.

Best Regards,
Ezio Melotti

> So if should be working, but you may have been caught in the SSL problem. If
> it persists then there's a problem in the hook-side of bugs.python.org that
> will need fixing.

From victor.stinner at gmail.com  Wed Feb 15 19:10:21 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 16 Feb 2017 01:10:21 +0100
Subject: [python-committers] New Roundup notifications on Git commits?
In-Reply-To: <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
References: <CAMpsgwbzA79tC9oREP9rmxtxJBOWrgKezWSnT2ESBg6vbO0C6A@mail.gmail.com>
 <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
Message-ID: <CAMpsgwahQZaCZ6utjwq7CFM_wvGCXwr_v_thOUasw7HKKsKGpQ@mail.gmail.com>

> New changeset 72e81d00eee685cfe33aaddf2aa9feef2d07591f by Victor Stinner in branch 'master':

Ok, I confirm that I now get notifications. Cool :-)

New request (!): would it be possible to mention the author instead of
the commiter? Or maybe mention both?

Thanks,
Victor

From ezio.melotti at gmail.com  Thu Feb 16 00:33:46 2017
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Thu, 16 Feb 2017 07:33:46 +0200
Subject: [python-committers] New Roundup notifications on Git commits?
In-Reply-To: <CAMpsgwahQZaCZ6utjwq7CFM_wvGCXwr_v_thOUasw7HKKsKGpQ@mail.gmail.com>
References: <CAMpsgwbzA79tC9oREP9rmxtxJBOWrgKezWSnT2ESBg6vbO0C6A@mail.gmail.com>
 <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
 <CAMpsgwahQZaCZ6utjwq7CFM_wvGCXwr_v_thOUasw7HKKsKGpQ@mail.gmail.com>
Message-ID: <CACBhJdESWg25Hfhxf2bgDu-n5=v0AoLN1oypY7+V_WxC4Ofw3Q@mail.gmail.com>

On Thu, Feb 16, 2017 at 2:10 AM, Victor Stinner
<victor.stinner at gmail.com> wrote:
>> New changeset 72e81d00eee685cfe33aaddf2aa9feef2d07591f by Victor Stinner in branch 'master':
>
> Ok, I confirm that I now get notifications. Cool :-)
>
> New request (!): would it be possible to mention the author instead of
> the commiter? Or maybe mention both?
>

If GitHub passes the information along (and it probably does), then it
should be possible to have both.
Please create an issue on the meta-tracker to keep track of this.

Best Regards,
Ezio Melotti

> Thanks,
> Victor

From victor.stinner at gmail.com  Thu Feb 16 04:42:27 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 16 Feb 2017 10:42:27 +0100
Subject: [python-committers] New Roundup notifications on Git commits?
In-Reply-To: <CACBhJdESWg25Hfhxf2bgDu-n5=v0AoLN1oypY7+V_WxC4Ofw3Q@mail.gmail.com>
References: <CAMpsgwbzA79tC9oREP9rmxtxJBOWrgKezWSnT2ESBg6vbO0C6A@mail.gmail.com>
 <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
 <CAMpsgwahQZaCZ6utjwq7CFM_wvGCXwr_v_thOUasw7HKKsKGpQ@mail.gmail.com>
 <CACBhJdESWg25Hfhxf2bgDu-n5=v0AoLN1oypY7+V_WxC4Ofw3Q@mail.gmail.com>
Message-ID: <CAMpsgwZBNPTqJ=3q17bnHgf7Kv+samXkMQPNNR0jPGm8XO+gQw@mail.gmail.com>

What and where is the meta-tracker? Is it
http://github.com/python/core-workflow/?

Victor

2017-02-16 6:33 GMT+01:00 Ezio Melotti <ezio.melotti at gmail.com>:
> On Thu, Feb 16, 2017 at 2:10 AM, Victor Stinner
> <victor.stinner at gmail.com> wrote:
>>> New changeset 72e81d00eee685cfe33aaddf2aa9feef2d07591f by Victor Stinner in branch 'master':
>>
>> Ok, I confirm that I now get notifications. Cool :-)
>>
>> New request (!): would it be possible to mention the author instead of
>> the commiter? Or maybe mention both?
>>
>
> If GitHub passes the information along (and it probably does), then it
> should be possible to have both.
> Please create an issue on the meta-tracker to keep track of this.
>
> Best Regards,
> Ezio Melotti
>
>> Thanks,
>> Victor

From storchaka at gmail.com  Thu Feb 16 05:25:00 2017
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 16 Feb 2017 12:25:00 +0200
Subject: [python-committers] New Roundup notifications on Git commits?
In-Reply-To: <CAMpsgwZBNPTqJ=3q17bnHgf7Kv+samXkMQPNNR0jPGm8XO+gQw@mail.gmail.com>
References: <CAMpsgwbzA79tC9oREP9rmxtxJBOWrgKezWSnT2ESBg6vbO0C6A@mail.gmail.com>
 <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
 <CAMpsgwahQZaCZ6utjwq7CFM_wvGCXwr_v_thOUasw7HKKsKGpQ@mail.gmail.com>
 <CACBhJdESWg25Hfhxf2bgDu-n5=v0AoLN1oypY7+V_WxC4Ofw3Q@mail.gmail.com>
 <CAMpsgwZBNPTqJ=3q17bnHgf7Kv+samXkMQPNNR0jPGm8XO+gQw@mail.gmail.com>
Message-ID: <CAAuNNr4QwXNkPAM=cSKnT5boNOa+yP2+mfqOjUn6V6V9Jepuww@mail.gmail.com>

2017-02-16 11:42 GMT+02:00 Victor Stinner <victor.stinner at gmail.com>:
> What and where is the meta-tracker? Is it
> http://github.com/python/core-workflow/?

http://psf.upfronthosting.co.za/roundup/meta/ I suppose.

From victor.stinner at gmail.com  Thu Feb 16 08:30:06 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 16 Feb 2017 14:30:06 +0100
Subject: [python-committers] Mercurial commit url is broken
Message-ID: <CAMpsgwbiwdsyNQbnaAQRBbrku0wYjF3+jPGBEz=6QU_C6dUf1Q@mail.gmail.com>

Hi,

I clicked on a Mercurial commit number from:
http://bugs.python.org/issue18383#msg249581

It points me to:
http://hg.python.org/lookup/c1396d28c440

... which displays short error message:
---
Usage: /lookup/GITHEXHASH or gitGITHEXHASH (10, 11, or 40 hex characters)
/lookup/HGHEXNODE or hgHGHEXNODE (12 or 40 hex characters)
/lookup/rSVNREVISION
---

"c1396d28c440" hash is 12 hex characters long.

Victor

From brett at python.org  Thu Feb 16 11:23:15 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 16 Feb 2017 16:23:15 +0000
Subject: [python-committers] Mercurial commit url is broken
In-Reply-To: <CAMpsgwbiwdsyNQbnaAQRBbrku0wYjF3+jPGBEz=6QU_C6dUf1Q@mail.gmail.com>
References: <CAMpsgwbiwdsyNQbnaAQRBbrku0wYjF3+jPGBEz=6QU_C6dUf1Q@mail.gmail.com>
Message-ID: <CAP1=2W6b1_9bnnqtqmCsXM-+AiX5QHea=myXrafFmVH+cS+qeQ@mail.gmail.com>

I'm going on vacation in literally 10 minutes, so the best I can do is tell
you is that a copy of the code can be found at
https://gist.github.com/brettcannon/f8d97c92b0df264cd4db008ffd32daf9 and
it's possible I screwed up the static JSON data file that I had the
infrastructure team install with the file.

On Thu, Feb 16, 2017, 05:30 Victor Stinner, <victor.stinner at gmail.com>
wrote:

> Hi,
>
> I clicked on a Mercurial commit number from:
> http://bugs.python.org/issue18383#msg249581
>
> It points me to:
> http://hg.python.org/lookup/c1396d28c440
>
> ... which displays short error message:
> ---
> Usage: /lookup/GITHEXHASH or gitGITHEXHASH (10, 11, or 40 hex characters)
> /lookup/HGHEXNODE or hgHGHEXNODE (12 or 40 hex characters)
> /lookup/rSVNREVISION
> ---
>
> "c1396d28c440" hash is 12 hex characters long.
>
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170216/5fbe7609/attachment-0001.html>

From brett at python.org  Thu Feb 16 11:24:13 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 16 Feb 2017 16:24:13 +0000
Subject: [python-committers] New Roundup notifications on Git commits?
In-Reply-To: <CAAuNNr4QwXNkPAM=cSKnT5boNOa+yP2+mfqOjUn6V6V9Jepuww@mail.gmail.com>
References: <CAMpsgwbzA79tC9oREP9rmxtxJBOWrgKezWSnT2ESBg6vbO0C6A@mail.gmail.com>
 <CAP1=2W614mRbCyT+EjYAvEvuRMkExfqzd96h+=brV4xD-ZsLow@mail.gmail.com>
 <CAMpsgwahQZaCZ6utjwq7CFM_wvGCXwr_v_thOUasw7HKKsKGpQ@mail.gmail.com>
 <CACBhJdESWg25Hfhxf2bgDu-n5=v0AoLN1oypY7+V_WxC4Ofw3Q@mail.gmail.com>
 <CAMpsgwZBNPTqJ=3q17bnHgf7Kv+samXkMQPNNR0jPGm8XO+gQw@mail.gmail.com>
 <CAAuNNr4QwXNkPAM=cSKnT5boNOa+yP2+mfqOjUn6V6V9Jepuww@mail.gmail.com>
Message-ID: <CAP1=2W4f7mRFLMJrmCmonGmz=7M62K2jOSQ=rmmD=Ry4PhE9QQ@mail.gmail.com>

On Thu, Feb 16, 2017, 02:25 Serhiy Storchaka, <storchaka at gmail.com> wrote:

> 2017-02-16 11:42 GMT+02:00 Victor Stinner <victor.stinner at gmail.com>:
> > What and where is the meta-tracker? Is it
> > http://github.com/python/core-workflow/?
>
> http://psf.upfronthosting.co.za/roundup/meta/ I suppose.
>

Serhiy's link is correct.

-Brett


_______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170216/45064177/attachment.html>

From ezio.melotti at gmail.com  Fri Feb 17 22:03:28 2017
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sat, 18 Feb 2017 05:03:28 +0200
Subject: [python-committers] Mercurial commit url is broken
In-Reply-To: <CAMpsgwbiwdsyNQbnaAQRBbrku0wYjF3+jPGBEz=6QU_C6dUf1Q@mail.gmail.com>
References: <CAMpsgwbiwdsyNQbnaAQRBbrku0wYjF3+jPGBEz=6QU_C6dUf1Q@mail.gmail.com>
Message-ID: <CACBhJdEmi=1-1eU3Z67MpLfzn2yT4dGMgcdoFQZYmFeV_DirXQ@mail.gmail.com>

On Thu, Feb 16, 2017 at 3:30 PM, Victor Stinner
<victor.stinner at gmail.com> wrote:
> Hi,
>
> I clicked on a Mercurial commit number from:
> http://bugs.python.org/issue18383#msg249581
>
> It points me to:
> http://hg.python.org/lookup/c1396d28c440
>

FTR the URL works now -- not sure if someone fixed it in the meanwhile.

Best Regards,
Ezio Melotti

> ... which displays short error message:
> ---
> Usage: /lookup/GITHEXHASH or gitGITHEXHASH (10, 11, or 40 hex characters)
> /lookup/HGHEXNODE or hgHGHEXNODE (12 or 40 hex characters)
> /lookup/rSVNREVISION
> ---
>
> "c1396d28c440" hash is 12 hex characters long.
>
> Victor

From nad at python.org  Mon Feb 20 15:12:47 2017
From: nad at python.org (Ned Deily)
Date: Mon, 20 Feb 2017 15:12:47 -0500
Subject: [python-committers] IMPORTANT: Python 3.6.1 Maintenance Release
 Release Candidate in 7 days (2017-02-27)
Message-ID: <9DEC04ED-5B6E-45CE-AC83-4A9CD8EBF829@python.org>

It seems like last year already since the release of 3.6.0.  I guess that's because it was last year, 2016-12-22 to be exact!  Now we're approaching the end of the first quarter and, according to PEP 494, it's time to start producing the first maintenance release for the 3.6 series.  The schedule calls for the release candidate to be produced on Monday 2017-02-27 UTC.  As was the case with the 3.6.0 release cycle, the plan is for the release candidate to be the same as the final release, that is, no additional changes go in after the release candidate except for any showstopper critical problems that might be discovered with rc1.  So please plan to get any security fixes, bug fixes, and documentation changes you think should be in 3.6.1 merged in before 2017-02-27.  I will send out another reminder a couple of days before. The 3.6.1 final is planned for two weeks following rc1, that is, on 2017-03-13.  I expect the next 3.6 maintenance release (3.6.2) will follow about 3 months later, so most likely in 2017-06 after PyCon US.  

3.6.1 will be the first release using our new GitHub-based development process (thanks, Brett and team!).  If you are planning to push something for 3.6.1 and haven't yet tried out the new workflow or are not yet familiar with GitHub pull requests, you should probably give yourself some extra time.  As always, the Developer's Guide is the primary reference for the development workflow; not surprisingly, with such a major change, there are likely still some parts of the guide that could use further changes and clarifications.  You can help by reviewing the devguide's open issues and pull requests in its repository and adding to them as you work through issues.  If you have comments on or improvement suggestions for the new workflow, the place to discuss them is on the core-workflow mailing list.

Thanks again for all of your efforts in bringing 3.6.0 into the world and for helping now to make it even better!

https://www.python.org/dev/peps/pep-0494/
http://cpython-devguide.readthedocs.io
https://mail.python.org/mailman/listinfo/core-workflow

--
  Ned Deily
  nad at python.org -- []


From victor.stinner at gmail.com  Fri Feb 24 05:30:35 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 24 Feb 2017 11:30:35 +0100
Subject: [python-committers] Date of the Language Summit at Pycon US 2017?
Message-ID: <CAMpsgwagTYTJV4p1bhjAs8vgR1_wtvHcqOL7b+oqbnW-BUxzqw@mail.gmail.com>

Hi,

I'm going to book my hotel and flight for Pycon US, but I don't know
the date of the Language Summit and I would prefer to not miss it if
possible :-)

Does someone organize it?

Victor

From christian at python.org  Fri Feb 24 07:09:11 2017
From: christian at python.org (Christian Heimes)
Date: Fri, 24 Feb 2017 13:09:11 +0100
Subject: [python-committers] Date of the Language Summit at Pycon US
 2017?
In-Reply-To: <CAMpsgwagTYTJV4p1bhjAs8vgR1_wtvHcqOL7b+oqbnW-BUxzqw@mail.gmail.com>
References: <CAMpsgwagTYTJV4p1bhjAs8vgR1_wtvHcqOL7b+oqbnW-BUxzqw@mail.gmail.com>
Message-ID: <f9c97db2-708c-7e98-8ba6-6f24ff600d02@python.org>

On 2017-02-24 11:30, Victor Stinner wrote:
> Hi,
> 
> I'm going to book my hotel and flight for Pycon US, but I don't know
> the date of the Language Summit and I would prefer to not miss it if
> possible :-)
> 
> Does someone organize it?

The language summit is usually on the first day of tutorials, so May 17,
https://us.pycon.org/2017/schedule/tutorials/ . [BL]arry are organizing
the summit.

Christian


From barry at python.org  Fri Feb 24 09:41:53 2017
From: barry at python.org (Barry Warsaw)
Date: Fri, 24 Feb 2017 09:41:53 -0500
Subject: [python-committers] Date of the Language Summit at Pycon US
 2017?
In-Reply-To: <CAMpsgwagTYTJV4p1bhjAs8vgR1_wtvHcqOL7b+oqbnW-BUxzqw@mail.gmail.com>
References: <CAMpsgwagTYTJV4p1bhjAs8vgR1_wtvHcqOL7b+oqbnW-BUxzqw@mail.gmail.com>
Message-ID: <20170224094153.27b02b92@subdivisions.wooz.org>

On Feb 24, 2017, at 11:30 AM, Victor Stinner wrote:

>I'm going to book my hotel and flight for Pycon US, but I don't know
>the date of the Language Summit and I would prefer to not miss it if
>possible :-)

Yep, [BL]arry will do it again this year, probably at least 50% under fez
duress.

https://us.pycon.org/2017/events/language-summit/

To keep things as topical as possible[*] we won't send out a call for
participation yet, but at least you should be able to plan for it.

evil-or-good-half-ly y'rs,
-Barry

[*] Last year we had a topic get mooted a day or so before the summit. ;)

From brett at python.org  Fri Feb 24 19:26:39 2017
From: brett at python.org (Brett Cannon)
Date: Sat, 25 Feb 2017 00:26:39 +0000
Subject: [python-committers] PRs now require Travis to be green,
 don't require a review
Message-ID: <CAP1=2W4ejveor=mej4b5sGOiE3==kGFgwNwPo6eU_Y8ga9HJZQ@mail.gmail.com>

I don't know about the rest of you but I can't believe it's only been two
weeks since we moved over to GitHub! Hopefully people are still viewing it
in a positive light. :)

One complaint I have heard consistently is the required review sign-off on
PRs. To do some A/B testing of this, I have switched that requirement off
but switched on the requirement that Travis tests be passing.

In two weeks I will be starting a conversation about the new workflow to
find out what people think we need to tweak, add/create, or remove in the
process. At that point we can make a final call if this situation is better
than requiring reviews, or if we want both CI and reviews for each PR.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170225/d3772153/attachment.html>

From nad at python.org  Sun Feb 26 17:19:00 2017
From: nad at python.org (Ned Deily)
Date: Sun, 26 Feb 2017 17:19:00 -0500
Subject: [python-committers] IMPORTANT: Python 3.6.1 RC delayed 4 days,
 now 2017-03-03
References: <9DEC04ED-5B6E-45CE-AC83-4A9CD8EBF829@python.org>
Message-ID: <BECD37E1-7A89-47E4-9ED0-3BCD03E78634@python.org>

I had previously announced tomorrow as the date for the release candidate of our first 3.6 maintenance release.  But, with the switchover to the new GitHub-based development process, there are a number of changes needed behind the scenes to our release production process and I think the release team (read "Ned") needs a few more days to get ready to produce the release.  So, reluctantly, I'm delaying the cutoff and production of 3.6.1rc1 for 4 days, that is, until Friday 2017-03-03 UTC.  As a plus, it gives us all a few more days to tackle the release-blocker, deferred-blocker, and critical issues still open against 3.6 and also to keep working though the new development process.  For now, I'm not changing the date for 3.6.1 final (2017-03-13) until we see how rc1 goes.

My apologies for the delay!

--Ned

 
Begin forwarded message:
> From: Ned Deily <nad at python.org>
> Subject: IMPORTANT: Python 3.6.1 Maintenance Release Release Candidate in 7 days (2017-02-27)
> Date: February 20, 2017 at 15:12:47 EST
> To: python-committers <python-committers at python.org>
> Cc: Python Dev <python-dev at python.org>
> 
> It seems like last year already since the release of 3.6.0.  I guess that's because it was last year, 2016-12-22 to be exact!  Now we're approaching the end of the first quarter and, according to PEP 494, it's time to start producing the first maintenance release for the 3.6 series.  The schedule calls for the release candidate to be produced on Monday 2017-02-27 UTC.  As was the case with the 3.6.0 release cycle, the plan is for the release candidate to be the same as the final release, that is, no additional changes go in after the release candidate except for any showstopper critical problems that might be discovered with rc1.  So please plan to get any security fixes, bug fixes, and documentation changes you think should be in 3.6.1 merged in before 2017-02-27.  I will send out another reminder a couple of days before. The 3.6.1 final is planned for two weeks following rc1, that is, on 2017-03-13.  I expect the next 3.6 maintenance release (3.6.2) will follow about 3 months later, so most likely in 2017-06 after PyCon US.  
> 
> 3.6.1 will be the first release using our new GitHub-based development process (thanks, Brett and team!).  If you are planning to push something for 3.6.1 and haven't yet tried out the new workflow or are not yet familiar with GitHub pull requests, you should probably give yourself some extra time.  As always, the Developer's Guide is the primary reference for the development workflow; not surprisingly, with such a major change, there are likely still some parts of the guide that could use further changes and clarifications.  You can help by reviewing the devguide's open issues and pull requests in its repository and adding to them as you work through issues.  If you have comments on or improvement suggestions for the new workflow, the place to discuss them is on the core-workflow mailing list.
> 
> Thanks again for all of your efforts in bringing 3.6.0 into the world and for helping now to make it even better!
> 
> https://www.python.org/dev/peps/pep-0494/
> http://cpython-devguide.readthedocs.io
> https://mail.python.org/mailman/listinfo/core-workflow

--
  Ned Deily
  nad at python.org -- []


From victor.stinner at gmail.com  Mon Feb 27 08:45:41 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 27 Feb 2017 14:45:41 +0100
Subject: [python-committers] No more notifications of commits (merged PR) on
 bpo?
Message-ID: <CAMpsgwZsT0un2Tk_s45h9L9QDKco96VXn+fxQogSpGxE=7mo9g@mail.gmail.com>

Hi,

My PR was merged, but I don't see any notification on bpo:
https://github.com/python/cpython/pull/253
http://bugs.python.org/issue27840

A few weeks ago, we got two notifications per commit (hg, git), and
now there is zero notification :-)

Is it a known issue?

Victor

From berker.peksag at gmail.com  Mon Feb 27 09:04:41 2017
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Mon, 27 Feb 2017 17:04:41 +0300
Subject: [python-committers] No more notifications of commits (merged
 PR) on bpo?
In-Reply-To: <CAMpsgwZsT0un2Tk_s45h9L9QDKco96VXn+fxQogSpGxE=7mo9g@mail.gmail.com>
References: <CAMpsgwZsT0un2Tk_s45h9L9QDKco96VXn+fxQogSpGxE=7mo9g@mail.gmail.com>
Message-ID: <CAF4280J2JmgZqWwhfcVm3pc5w8F0UsG-Q4YzzXm1yq-0XX1EuA@mail.gmail.com>

On Mon, Feb 27, 2017 at 4:45 PM, Victor Stinner
<victor.stinner at gmail.com> wrote:
> Hi,
>
> My PR was merged, but I don't see any notification on bpo:
> https://github.com/python/cpython/pull/253
> http://bugs.python.org/issue27840
>
> A few weeks ago, we got two notifications per commit (hg, git), and
> now there is zero notification :-)
>
> Is it a known issue?

http://psf.upfronthosting.co.za/roundup/meta/issue613

--Berker