From vstinner at redhat.com Wed May 2 05:49:36 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 2 May 2018 11:49:36 +0200 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? Message-ID: Hi, I would like to start a poll on Chris Angelico's PEP 572 "Assignment Expressions", restricted to Python core developers, to prepare the talk at the Language Summit: https://www.python.org/dev/peps/pep-0572/ The poll is on the *current* PEP. I propose 4 choices: * +1: you like the PEP * -1: you dislike the PEP * 0: you are not sure if you like it or not, or you have no opinon * don't reply to this poll :-) Just reply to this email with "+1", "0", "-1". Please don't elaborate here, it's just a quick poll, use python-dev if you want to talk :-) The poll will end next Tuesday, May 8, the day before the Language Summit. I propose a poll because I'm unable to track the opinion of each core dev, too many emails have been sent to python-dev, and maybe some people changed their mind during the long discussion (which started in February) :-) Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the one who will pronounce himself on the PEP, to accept to reject it, so the only one allowed to vote ;-) Victor From vstinner at redhat.com Wed May 2 05:50:27 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 2 May 2018 11:50:27 +0200 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: -1: dislike ( my rationale: https://mail.python.org/pipermail/python-dev/2018-April/152991.html ) Victor From antoine at python.org Wed May 2 05:55:34 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 2 May 2018 11:55:34 +0200 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: <39a0adfa-6042-40c4-0392-d0176672c1d2@python.org> -1: dislike Regards Antoine. Le 02/05/2018 ? 11:49, Victor Stinner a ?crit?: > Hi, > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: > > https://www.python.org/dev/peps/pep-0572/ > > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) > > Just reply to this email with "+1", "0", "-1". Please don't elaborate > here, it's just a quick poll, use python-dev if you want to talk :-) > > The poll will end next Tuesday, May 8, the day before the Language Summit. > > I propose a poll because I'm unable to track the opinion of each core > dev, too many emails have been sent to python-dev, and maybe some > people changed their mind during the long discussion (which started in > February) :-) > > Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the > one who will pronounce himself on the PEP, to accept to reject it, so > the only one allowed to vote ;-) > > 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/ > From p.f.moore at gmail.com Wed May 2 05:56:44 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 2 May 2018 10:56:44 +0100 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: On 2 May 2018 at 10:49, Victor Stinner wrote: > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: Do we really need this spilling over into yet another mailing list? Paul From vstinner at redhat.com Wed May 2 06:13:21 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 2 May 2018 12:13:21 +0200 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: 2018-05-02 11:56 GMT+02:00 Paul Moore : > On 2 May 2018 at 10:49, Victor Stinner wrote: >> I would like to start a poll on Chris Angelico's PEP 572 "Assignment >> Expressions", restricted to Python core developers, to prepare the >> talk at the Language Summit: > > Do we really need this spilling over into yet another mailing list? I already saw polls on Twitter, but I don't know if I should trust Twitter polls because of the filter bubble. Moreover, this poll is restricted to core developers, so it's different. There will be a session about the PEP 572 next week at the Language Summit, but I'm afraid that the session may go in all directions since I didn't see any explicit agenda nor moderator yet: https://mail.python.org/pipermail/python-dev/2018-April/153250.html I would prefer to prepare the session to be more efficient. I also care of other topics discussed the Language Summit. The poll is also for the ones who will not be able to attend the Language Summit. By the way, the list of sessions is not available yet, Larry/Barry? https://us.pycon.org/2018/events/language-summit/ Victor From songofacandy at gmail.com Wed May 2 06:06:35 2018 From: songofacandy at gmail.com (INADA Naoki) Date: Wed, 02 May 2018 10:06:35 +0000 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: 0: I will use it if it's accepted, but I'm not sure it's merit is enough for changing how Python code looks. From levkivskyi at gmail.com Wed May 2 06:43:58 2018 From: levkivskyi at gmail.com (Ivan Levkivskyi) Date: Wed, 2 May 2018 11:43:58 +0100 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: 0: this might be a handy feature, but I am not sure the dangers it introduces are adequate for the problem it solves. -- Ivan On 2 May 2018 at 11:06, INADA Naoki wrote: > 0: I will use it if it's accepted, but I'm not sure it's merit is enough > for changing how Python code looks. > _______________________________________________ > 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: From berker.peksag at gmail.com Wed May 2 07:49:46 2018 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Wed, 2 May 2018 14:49:46 +0300 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: On Wed, May 2, 2018 at 12:49 PM, Victor Stinner wrote: > Hi, > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: > > https://www.python.org/dev/peps/pep-0572/ > > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) -1 (I'd vote +1 if it was fully backwards-compatible.) --Berker From vstinner at redhat.com Wed May 2 08:04:37 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 2 May 2018 14:04:37 +0200 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: 2018-05-02 11:49 GMT+02:00 Victor Stinner : > Just reply to this email with "+1", "0", "-1". Please don't elaborate > here, it's just a quick poll, use python-dev if you want to talk :-) FYI if you want don't to spam python-committers list, you may reply to me in private. I will publish poll results at the end of the poll. Victor From mal at egenix.com Wed May 2 09:11:32 2018 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 2 May 2018 15:11:32 +0200 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: <7ad6ef71-59d7-77ee-1c81-27251bf8e220@egenix.com> -1 in the current form, since an expression such as [y := f(x), x/y] ... is confusing (I'd read this as [y := (f(x), x/y)] Using explicit parens around it would resolve this issue: [(y := f(x)), x/y] ... but even with that, I'm not excited about the additional line noise this adds - there's a reason why we have for-loops in the language after all, explicit is better than having to look thrice, etc. etc. :-) Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 02 2018) >>> 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/ On 02.05.2018 11:49, Victor Stinner wrote: > Hi, > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: > > https://www.python.org/dev/peps/pep-0572/ > > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) > > Just reply to this email with "+1", "0", "-1". Please don't elaborate > here, it's just a quick poll, use python-dev if you want to talk :-) > > The poll will end next Tuesday, May 8, the day before the Language Summit. > > I propose a poll because I'm unable to track the opinion of each core > dev, too many emails have been sent to python-dev, and maybe some > people changed their mind during the long discussion (which started in > February) :-) > > Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the > one who will pronounce himself on the PEP, to accept to reject it, so > the only one allowed to vote ;-) > > 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/ > From ncoghlan at gmail.com Wed May 2 09:45:11 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 2 May 2018 23:45:11 +1000 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: On 2 May 2018 at 19:49, Victor Stinner wrote: > Hi, > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: > > https://www.python.org/dev/peps/pep-0572/ > > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) > -1 from me (on "too much pain for not enough gain" grounds). Regards, Nick. P.S. I quite liked the initial "expr as name" version with subscopes, but those aspects were changed based on reasonable concerns raised on python-ideas, and I think the discussion of the simplified proposal on python-dev has also raised sufficient further concerns to push the whole concept back into python-ideas territory. (I do think the discussions have clarified the nature of the cases where the current lack of any form of inline binding support can be genuinely irritating, though) -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Wed May 2 10:00:51 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 2 May 2018 15:00:51 +0100 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: FWIW, -1 from me. At least with the PEP as it stands. Paul From ericsnowcurrently at gmail.com Wed May 2 10:02:21 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Wed, 2 May 2018 08:02:21 -0600 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: On Wed, May 2, 2018 at 3:49 AM, Victor Stinner wrote: > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) > > Just reply to this email with "+1", "0", "-1". Please don't elaborate > here, it's just a quick poll, use python-dev if you want to talk :-) -1 ...and thanks for specifically asking for no elaboration. I was tempted. :) -eric From yselivanov.ml at gmail.com Wed May 2 10:10:07 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Wed, 02 May 2018 14:10:07 +0000 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: -1 On Wed, May 2, 2018 at 10:02 AM Eric Snow wrote: > On Wed, May 2, 2018 at 3:49 AM, Victor Stinner wrote: > > The poll is on the *current* PEP. I propose 4 choices: > > > > * +1: you like the PEP > > * -1: you dislike the PEP > > * 0: you are not sure if you like it or not, or you have no opinon > > * don't reply to this poll :-) > > > > Just reply to this email with "+1", "0", "-1". Please don't elaborate > > here, it's just a quick poll, use python-dev if you want to talk :-) > -1 > ...and thanks for specifically asking for no elaboration. I was tempted. :) > -eric > _______________________________________________ > 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/ -- Yury From stefan at bytereef.org Wed May 2 10:17:56 2018 From: stefan at bytereef.org (Stefan Krah) Date: Wed, 2 May 2018 16:17:56 +0200 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: <20180502141756.GA5188@bytereef.org> +0.5 Stefan Krah From tim.peters at gmail.com Wed May 2 12:11:31 2018 From: tim.peters at gmail.com (Tim Peters) Date: Wed, 2 May 2018 11:11:31 -0500 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) +1 From jaraco at jaraco.com Wed May 2 12:32:30 2018 From: jaraco at jaraco.com (Jason R. Coombs) Date: Wed, 2 May 2018 16:32:30 +0000 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: +1 On 2 May, 2018, at 10:49, Victor Stinner > wrote: * +1: you like the PEP * -1: you dislike the PEP * 0: you are not sure if you like it or not, or you have no opinon * don't reply to this poll :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Wed May 2 12:54:24 2018 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 2 May 2018 12:54:24 -0400 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: -1 On Wed, May 2, 2018 at 5:49 AM, Victor Stinner wrote: > Hi, > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: > > https://www.python.org/dev/peps/pep-0572/ > > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) > > Just reply to this email with "+1", "0", "-1". Please don't elaborate > here, it's just a quick poll, use python-dev if you want to talk :-) > > The poll will end next Tuesday, May 8, the day before the Language Summit. > > I propose a poll because I'm unable to track the opinion of each core > dev, too many emails have been sent to python-dev, and maybe some > people changed their mind during the long discussion (which started in > February) :-) > > Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the > one who will pronounce himself on the PEP, to accept to reject it, so > the only one allowed to vote ;-) > > 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/ From lukasz at langa.pl Wed May 2 12:56:54 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Wed, 2 May 2018 09:56:54 -0700 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: -1 -- Best regards, ?ukasz Langa > On May 2, 2018, at 2:49 AM, Victor Stinner wrote: > > Hi, > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: > > https://www.python.org/dev/peps/pep-0572/ > > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) > > Just reply to this email with "+1", "0", "-1". Please don't elaborate > here, it's just a quick poll, use python-dev if you want to talk :-) > > The poll will end next Tuesday, May 8, the day before the Language Summit. > > I propose a poll because I'm unable to track the opinion of each core > dev, too many emails have been sent to python-dev, and maybe some > people changed their mind during the long discussion (which started in > February) :-) > > Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the > one who will pronounce himself on the PEP, to accept to reject it, so > the only one allowed to vote ;-) > > 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/ From Stefan.Richthofer at gmx.de Wed May 2 13:40:41 2018 From: Stefan.Richthofer at gmx.de (Stefan Richthofer) Date: Wed, 2 May 2018 19:40:41 +0200 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: -1 -Stefan > > On May 2, 2018, at 2:49 AM, Victor Stinner wrote: > > > > Hi, > > > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > > Expressions", restricted to Python core developers, to prepare the > > talk at the Language Summit: > > > > https://www.python.org/dev/peps/pep-0572/ > > > > The poll is on the *current* PEP. I propose 4 choices: > > > > * +1: you like the PEP > > * -1: you dislike the PEP > > * 0: you are not sure if you like it or not, or you have no opinon > > * don't reply to this poll :-) > > > > Just reply to this email with "+1", "0", "-1". Please don't elaborate > > here, it's just a quick poll, use python-dev if you want to talk :-) > > > > The poll will end next Tuesday, May 8, the day before the Language Summit. > > > > I propose a poll because I'm unable to track the opinion of each core > > dev, too many emails have been sent to python-dev, and maybe some > > people changed their mind during the long discussion (which started in > > February) :-) > > > > Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the > > one who will pronounce himself on the PEP, to accept to reject it, so > > the only one allowed to vote ;-) > > > > 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 julien at palard.fr Wed May 2 15:33:44 2018 From: julien at palard.fr (Julien Palard) Date: Wed, 02 May 2018 15:33:44 -0400 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: -1 ?--? Julien Palard https://mdk.fr? From storchaka at gmail.com Wed May 2 16:27:47 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Wed, 2 May 2018 23:27:47 +0300 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: 02.05.18 12:49, Victor Stinner ????: > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) > > Just reply to this email with "+1", "0", "-1". Please don't elaborate > here, it's just a quick poll, use python-dev if you want to talk :-) -1: dislike I will not use it if it's accepted, and likely will not make reviews of patches that use it. From storchaka at gmail.com Wed May 2 17:18:31 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Thu, 3 May 2018 00:18:31 +0300 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: <0b95b46c-a421-1ff7-c127-35a33c6c23e4@gmail.com> 02.05.18 23:27, Serhiy Storchaka ????: > I will not use it if it's accepted, and likely will not make reviews > of patches that use it. I meant that this feature looks so bad to me, that it will be painful to me even to read a Python code that uses it. From tjreedy at udel.edu Wed May 2 19:03:39 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 2 May 2018 19:03:39 -0400 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: <1b5ebae9-ff46-5fd6-fd0a-f6a96b72cab7@udel.edu> On 5/2/2018 5:49 AM, Victor Stinner wrote: You asked two different questions, hence two answers. 1. The title asks "Do I like the PEP 572 Assignment Expressions"? Yes, at least +.5, and if forced, I might well round up to 1. > The poll is on the *current* PEP. I propose 4 choices: 2. However, the PEP itself also contains an only loosely related and inadequately discussed proposal to change comprehension scoping semantics (I presume before we are done with 2.7) and possibly break existing code without a deprecation period. I think all 3 aspects of this are wrong. Hence I am -1 on this part of the PEP and the PEP as a whole. I think some, but not all, of other answers are influenced by which version of the question a person is answering. TJR From steve.dower at python.org Wed May 2 20:04:52 2018 From: steve.dower at python.org (Steve Dower) Date: Wed, 2 May 2018 17:04:52 -0700 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: On 02May2018 0249, Victor Stinner wrote: > * +1: you like the PEP > * -1: you dislike the PEP I love the PEP, it's one of the better ones for sure. :) I just don't like the proposed change. -1 Cheers, Steve From robertc at robertcollins.net Wed May 2 20:28:57 2018 From: robertc at robertcollins.net (Robert Collins) Date: Thu, 3 May 2018 12:28:57 +1200 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: I'd very much like the feature, but not sure that the proposed change is a good fit today. -Rob On 2 May 2018 at 22:13, Victor Stinner wrote: > 2018-05-02 11:56 GMT+02:00 Paul Moore : >> On 2 May 2018 at 10:49, Victor Stinner wrote: >>> I would like to start a poll on Chris Angelico's PEP 572 "Assignment >>> Expressions", restricted to Python core developers, to prepare the >>> talk at the Language Summit: >> >> Do we really need this spilling over into yet another mailing list? > > I already saw polls on Twitter, but I don't know if I should trust > Twitter polls because of the filter bubble. Moreover, this poll is > restricted to core developers, so it's different. > > There will be a session about the PEP 572 next week at the Language > Summit, but I'm afraid that the session may go in all directions since > I didn't see any explicit agenda nor moderator yet: > > https://mail.python.org/pipermail/python-dev/2018-April/153250.html > > I would prefer to prepare the session to be more efficient. I also > care of other topics discussed the Language Summit. > > The poll is also for the ones who will not be able to attend the > Language Summit. > > By the way, the list of sessions is not available yet, Larry/Barry? > > https://us.pycon.org/2018/events/language-summit/ > > 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/ From raymond.hettinger at gmail.com Wed May 2 21:39:31 2018 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Wed, 2 May 2018 18:39:31 -0700 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: -1: dislike > On May 2, 2018, at 2:49 AM, Victor Stinner wrote: > > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) > > Just reply to this email with "+1", "0", "-1". Please don't elaborate > here, it's just a quick poll, use python-dev if you want to talk :-) From christian at cheimes.de Thu May 3 06:50:41 2018 From: christian at cheimes.de (Christian Heimes) Date: Thu, 3 May 2018 12:50:41 +0200 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: <6c9a41a7-1a33-6af6-a1e9-1ac848c220b1@cheimes.de> On 2018-05-02 11:49, Victor Stinner wrote: > Hi, > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: > > https://www.python.org/dev/peps/pep-0572/ > > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) -1 From nad at python.org Wed May 2 20:16:25 2018 From: nad at python.org (Ned Deily) Date: Wed, 2 May 2018 20:16:25 -0400 Subject: [python-committers] [RELEASE] Python 3.7.0b4, final 3.7 beta, now available for testing Message-ID: <82F6CAB9-4144-4937-B73B-914AD6518173@python.org> Python 3.7.0b4 is the final beta preview of Python 3.7, the next feature release of Python. Beta releases are intended to give you the opportunity to test new features and bug fixes and to prepare your projects to support the new feature release. We strongly encourage you to test your projects with 3.7 during the beta phase and report issues found to bugs.python.org as soon as possible. While the release is feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase. Please keep in mind that this is a preview release and its use is not recommended for production environments. Attention macOS users: there is now a new installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default version when 3.7.0 releases. Check it out! The next preview release will be the release candidate and is planned for 2018-05-21 followed by the official release of 3.7.0, planned for 2018-06-15. You can find Python 3.7.0b4 and more information here: https://www.python.org/downloads/release/python-370b4/ -- Ned Deily nad at python.org -- [] From greg at krypto.org Thu May 3 14:25:12 2018 From: greg at krypto.org (Gregory P. Smith) Date: Thu, 3 May 2018 11:25:12 -0700 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: On Wed, May 2, 2018 at 2:49 AM, Victor Stinner wrote: > Hi, > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: > > https://www.python.org/dev/peps/pep-0572/ > > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) > -1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dickinsm at gmail.com Thu May 3 15:50:54 2018 From: dickinsm at gmail.com (Mark Dickinson) Date: Thu, 3 May 2018 20:50:54 +0100 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: On Wed, May 2, 2018 at 10:49 AM, Victor Stinner wrote: > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) > -1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Thu May 3 22:37:58 2018 From: njs at pobox.com (Nathaniel Smith) Date: Thu, 3 May 2018 19:37:58 -0700 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: -1, I think, though I'm frustrated that in the parts of the list discussion I had energy to read, its proponents seemed to be saying that the most compelling examples aren't actually in the PEP (and I don't know what they are). On Wed, May 2, 2018 at 2:49 AM, Victor Stinner wrote: > Hi, > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: > > https://www.python.org/dev/peps/pep-0572/ > > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) > > Just reply to this email with "+1", "0", "-1". Please don't elaborate > here, it's just a quick poll, use python-dev if you want to talk :-) > > The poll will end next Tuesday, May 8, the day before the Language Summit. > > I propose a poll because I'm unable to track the opinion of each core > dev, too many emails have been sent to python-dev, and maybe some > people changed their mind during the long discussion (which started in > February) :-) > > Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the > one who will pronounce himself on the PEP, to accept to reject it, so > the only one allowed to vote ;-) > > 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/ -- Nathaniel J. Smith -- https://vorpus.org From willingc at gmail.com Fri May 4 01:16:41 2018 From: willingc at gmail.com (Carol Willing) Date: Fri, 04 May 2018 05:16:41 +0000 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: -1 as currently proposed, +0 on Tim?s more bounded approach from the mailing list On Fri, May 4, 2018 at 4:38 AM Nathaniel Smith wrote: > -1, I think, though I'm frustrated that in the parts of the list > discussion I had energy to read, its proponents seemed to be saying > that the most compelling examples aren't actually in the PEP (and I > don't know what they are). > > On Wed, May 2, 2018 at 2:49 AM, Victor Stinner > wrote: > > Hi, > > > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > > Expressions", restricted to Python core developers, to prepare the > > talk at the Language Summit: > > > > https://www.python.org/dev/peps/pep-0572/ > > > > The poll is on the *current* PEP. I propose 4 choices: > > > > * +1: you like the PEP > > * -1: you dislike the PEP > > * 0: you are not sure if you like it or not, or you have no opinon > > * don't reply to this poll :-) > > > > Just reply to this email with "+1", "0", "-1". Please don't elaborate > > here, it's just a quick poll, use python-dev if you want to talk :-) > > > > The poll will end next Tuesday, May 8, the day before the Language > Summit. > > > > I propose a poll because I'm unable to track the opinion of each core > > dev, too many emails have been sent to python-dev, and maybe some > > people changed their mind during the long discussion (which started in > > February) :-) > > > > Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the > > one who will pronounce himself on the PEP, to accept to reject it, so > > the only one allowed to vote ;-) > > > > 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/ > > > > -- > Nathaniel J. Smith -- https://vorpus.org > _______________________________________________ > 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/ > -- *Carol Willing* Research Software Engineer Project Jupyter at Cal Poly SLO cawillin at calpoly.edu *Signature strengths* *Empathy - Relator - Ideation - Strategic - Learner* -------------- next part -------------- An HTML attachment was scrubbed... URL: From kushaldas at gmail.com Fri May 4 02:21:31 2018 From: kushaldas at gmail.com (Kushal Das) Date: Thu, 3 May 2018 23:21:31 -0700 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: On Wed, May 2, 2018 at 2:49 AM, Victor Stinner wrote: > Hi, > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: > > https://www.python.org/dev/peps/pep-0572/ > > The poll is on the *current* PEP. I propose 4 choices: > > * +1: you like the PEP > * -1: you dislike the PEP > * 0: you are not sure if you like it or not, or you have no opinon > * don't reply to this poll :-) -1 Kushal -- Staff, Freedom of the Press Foundation CPython Core Developer Director, Python Software Foundation https://kushaldas.in From ericsnowcurrently at gmail.com Fri May 4 11:29:49 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Fri, 4 May 2018 09:29:49 -0600 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: On Wed, May 2, 2018 at 3:49 AM, Victor Stinner wrote: > I propose a poll because I'm unable to track the opinion of each core > dev, too many emails have been sent to python-dev, and maybe some > people changed their mind during the long discussion (which started in > February) :-) FWIW, contrary to the many -1 responses, I don't think the actual sentiment is all torches-and-pitchforks. :) There are a variety of well-reasoned opinions that mostly result in "meh" and "I don't like the idea of it but don't know how it will actually work out" (or maybe I'm just projecting myself onto everyone else). This is the point where I have a lot of respect for Guido's uncanny intuition as reflected in Python's history. -eric From ericsnowcurrently at gmail.com Fri May 4 11:41:31 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Fri, 4 May 2018 09:41:31 -0600 Subject: [python-committers] My opinion about "binding expressions" (was Poll: Do you like the PEP 572 Assignment Expressions?) Message-ID: On Wed, May 2, 2018 at 3:49 AM, Victor Stinner wrote: > I propose a poll because I'm unable to track the opinion of each core > dev, too many emails have been sent to python-dev, and maybe some > people changed their mind during the long discussion (which started in > February) :-) Victor said "Please don't elaborate here" so I've opened yet another* thread for this topic. :) My apologies to all for that. However, I didn't feel like the poll captured my opinion well. In the interest of not adding too much more noise to the discussion on this specific topic, I'll provide a (relatively) brief opinion here and then bow out. (I don't feel like I have anything else to contribute on the subject.) If you feel similarly, feel free to do likewise (e.g. be concise). Please don't engage in discussion here. There are plenty of other threads for that. If no one else registers their opinion here that's fine with me too. :) As to my actual opinion, ultimately I don't think "binding expressions" are such a big deal either way. I doubt abuse will be as common or frustrating as that of list comprehensions and ternary expressions; but either way code review will mitigate that risk (and I doubt binding expressions will be a major distraction there). Anyway, I'll probably use them occasionally if we get them. -eric * Yeah, it's like when someone says "the problem is there are too many file formats" so they write their own to render the rest irrelevant... From vstinner at redhat.com Fri May 4 12:10:39 2018 From: vstinner at redhat.com (Victor Stinner) Date: Fri, 4 May 2018 18:10:39 +0200 Subject: [python-committers] PEP 572 at the Language Summit next week Message-ID: Sorry, I choose to reply to python-committers rather than python-dev because I have been annoyed by the PEP 572 traffic on python-dev. 2018-04-29 22:45 GMT+02:00 Larry Hastings : > In case it helps, we're planning on presentations on / a discussion of PEP > 572 at the 2018 Python Language Summit next Wednesday. (I'm assuming it > won't be pronounced upon before then--after all, what's the rush?) > Naturally the discussion isn't going to escape the room until it gets > reported on by Jake Edge, but delegates at the Summit will hopefully emerge > well-informed and comfortable with the result of the discussion. Who is going to lead this discussion? Will we have at least one developer in favor of the PEP to give a summary of the advantages? I would like to make sure that we can get a fair summary of the past PEP discussion. I'm not worried for the "dislike" part which may be correctly represented :-D Note: I just got a notice of a strike at Air France next Tuesday, the day I'm flighting to the US, and my 3rd and last flight of this trip is cancelled. Oh oh. Victor From guido at python.org Fri May 4 13:04:35 2018 From: guido at python.org (Guido van Rossum) Date: Fri, 4 May 2018 10:04:35 -0700 Subject: [python-committers] PEP 572 at the Language Summit next week In-Reply-To: References: Message-ID: It looks like I am going to try and present a balanced summary and then open the floor for discussion. I also want to use the opportunity to start brainstorming about a better way to make decisions. On Fri, May 4, 2018 at 9:10 AM, Victor Stinner wrote: > Sorry, I choose to reply to python-committers rather than python-dev > because I have been annoyed by the PEP 572 traffic on python-dev. > > 2018-04-29 22:45 GMT+02:00 Larry Hastings : > > In case it helps, we're planning on presentations on / a discussion of > PEP > > 572 at the 2018 Python Language Summit next Wednesday. (I'm assuming it > > won't be pronounced upon before then--after all, what's the rush?) > > Naturally the discussion isn't going to escape the room until it gets > > reported on by Jake Edge, but delegates at the Summit will hopefully > emerge > > well-informed and comfortable with the result of the discussion. > > Who is going to lead this discussion? Will we have at least one > developer in favor of the PEP to give a summary of the advantages? I > would like to make sure that we can get a fair summary of the past PEP > discussion. > > I'm not worried for the "dislike" part which may be correctly represented > :-D > > Note: I just got a notice of a strike at Air France next Tuesday, the > day I'm flighting to the US, and my 3rd and last flight of this trip > is cancelled. Oh oh. > > 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/ > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Fri May 4 17:29:14 2018 From: vstinner at redhat.com (Victor Stinner) Date: Fri, 4 May 2018 23:29:14 +0200 Subject: [python-committers] PEP 572 at the Language Summit next week In-Reply-To: References: Message-ID: 2018-05-04 19:04 GMT+02:00 Guido van Rossum : > It looks like I am going to try and present a balanced summary and then open > the floor for discussion. Oh ok, thanks! I'm not sure that the discussion on python-dev was really efficient (I didn't follow the discussion on python-ideas). It seems like many people said the same thing. I'm not sure that arguments of the supporters of the PEP have been heard. Likely lost in the high number of emails... Victor From tim.peters at gmail.com Fri May 4 19:31:00 2018 From: tim.peters at gmail.com (Tim Peters) Date: Fri, 4 May 2018 18:31:00 -0500 Subject: [python-committers] PEP 572 at the Language Summit next week In-Reply-To: References: Message-ID: [Victor Stinner ] > I'm not sure that the discussion on python-dev was really efficient (I > didn't follow the discussion on python-ideas). It seems like many > people said the same thing. Only hundreds of times ;-) > I'm not sure that arguments of the supporters of the PEP have been > heard. Likely lost in the high number of emails... It's really the PEP's job to lay out the pros and cons - you shouldn't have to read emails at all for that, unless you want to follow the development in real time. I think moving the PEP from python-ideas to python-dev was premature, because even among proponents there wasn't yet consensus that the then-current state of the PEP was sufficiently focused. The simpler the PEP has gotten, the more I've warmed to it. My current +1 isn't really about the PEP as it stands, but about what I _assume_ Guido will be talking about (plain-name "binding expressions" alone, and not also, e.g., about changing some corner case scope behaviors, but also about tightening the language spec with respect to guaranteeing a specific order-of-operation (OOO) in some currently fuzzy cases - although, to be fair, both scope behaviors and OOO guarantees are issues on their own quite independent of this PEP). And, frankly, everyone else should be +1 too on whatever it is Guido is privately thinking ;-) From steve.dower at python.org Fri May 4 19:40:41 2018 From: steve.dower at python.org (Steve Dower) Date: Fri, 4 May 2018 16:40:41 -0700 Subject: [python-committers] PEP 572 at the Language Summit next week In-Reply-To: References: Message-ID: On 04May2018 1631, Tim Peters wrote: > And, frankly, everyone else should be +1 too on whatever it is Guido > is privately thinking ;-) That wasn't what the poll was about :) Cheers, Steve From larry at hastings.org Fri May 4 20:52:02 2018 From: larry at hastings.org (Larry Hastings) Date: Fri, 4 May 2018 17:52:02 -0700 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: <3cb08ab2-be85-a031-57dc-4b019e1c9974@hastings.org> -1 //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Sun May 6 17:45:23 2018 From: senthil at uthcode.com (Senthil Kumaran) Date: Sun, 6 May 2018 14:45:23 -0700 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: <3cb08ab2-be85-a031-57dc-4b019e1c9974@hastings.org> References: <3cb08ab2-be85-a031-57dc-4b019e1c9974@hastings.org> Message-ID: -1. Registering my vote. I studied only the PEP and didn't follow the debate/discussion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.svetlov at gmail.com Mon May 7 13:44:07 2018 From: andrew.svetlov at gmail.com (Andrew Svetlov) Date: Mon, 07 May 2018 17:44:07 +0000 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: <3cb08ab2-be85-a031-57dc-4b019e1c9974@hastings.org> Message-ID: -1 On Mon, May 7, 2018 at 12:45 AM Senthil Kumaran wrote: > -1. > > Registering my vote. I studied only the PEP and didn't follow the > debate/discussion. > > _______________________________________________ > 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/ > -- Thanks, Andrew Svetlov -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Tue May 8 12:20:30 2018 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 9 May 2018 02:20:30 +1000 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: <20180508162030.GE9562@ando.pearwood.info> On Wed, May 02, 2018 at 11:49:36AM +0200, Victor Stinner wrote: > Hi, > > I would like to start a poll on Chris Angelico's PEP 572 "Assignment > Expressions", restricted to Python core developers, to prepare the > talk at the Language Summit: With the changes suggested by Guido, +1 (I've track of where the PEP itself is, and whether or not it includes the new suggestions.) -- Steve From ethan at stoneleaf.us Tue May 8 14:44:42 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Tue, 08 May 2018 11:44:42 -0700 Subject: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions? In-Reply-To: References: Message-ID: <5AF1F01A.5040407@stoneleaf.us> With Tim's and Guido's latest suggestions, +1 -- ~Ethan~ From vstinner at redhat.com Wed May 9 12:10:55 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 9 May 2018 12:10:55 -0400 Subject: [python-committers] Results of the poll: Do you like the PEP 572 Assignment Expressions? Message-ID: Hi, As announced last week, I publish the result of the poll I started on the *current* Chris Angelico's PEP 572 "Assignment Expressions": https://www.python.org/dev/peps/pep-0572/ Results: * Like (+1): 3 (8%) * Dislike (-1): 29 (76%) * No opinion (0): 6 (16%) Percents if you ignore no opinion: * Like (+1): 3 (9%) * Dislike (-1): 29 (91%) Two people voted on a variant of the PEP, so I excluded from my results: * Steven D'Aprano: With the changes suggested by Guido, +1 * Ethan Furman: With Tim's and Guido's latest suggestions, +1 Again, it was just a poll. Not a vote. Multiple people also added a second vote for a variant of the PEP. I only counted results on the current PEP version. It seems like "Tim's and Guido's latest suggestions" have big impact and are awaited :-) Like, vote: +1 ============== * Stefan Krah * Tim Peters * Jason R. Coombs Dislike, vote: -1 ================= * Victor Stinner * Antoine Pitrou * Tal Einat * Jack Jansen * Berker Peksa? * M.-A. Lemburg * Alex Gaynor * Nick Coghlan * Paul Moore * Eric Snow * Yury Selivanov * Facundo Batista * Alexander Belopolsky * ?ukasz Langa * Stefan Richthofer * Julien Palard * Serhiy Storchaka * Terry Reedy * Steve Dower * Raymond Hettinger * Christian Heimes * Gregory P. Smith * Mark Dickinson * Nathaniel Smith * Carol Willing * Kushal Das * Larry Hastings * Senthil Kumaran * Andrew Svetlov No opinion, vote: 0 =================== * INADA Naoki * Ivan Levkivskyi * Chris Jerdonek * Barry Warsaw * Ned Deily * Robert Collins Victor From mariatta.wijaya at gmail.com Mon May 14 14:21:48 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Mon, 14 May 2018 11:21:48 -0700 Subject: [python-committers] Orphaned backports In-Reply-To: References: <2dac841a-881f-40b6-646a-674459fe0cc1@udel.edu> <48cb8f3c-59c0-ad20-33b7-a78cb557b805@gmail.com> Message-ID: To help with this, miss-islington will now assign the PR where backport had failed to the core dev who merged the original PR. Mariatta On Tue, Apr 24, 2018 at 8:57 AM, Brett Cannon wrote: > > > On Tue, 24 Apr 2018 at 02:59 Serhiy Storchaka wrote: > >> 23.04.18 19:47, Brett Cannon ????: >> >> On Sun, 22 Apr 2018 at 11:27 Terry Reedy wrote: >> >>> Does github allow repository owners to send email directly to people who >>> have submitted PRs or at least, people with commit privileges (in this >>> case, those whose have done particular merges)? >>> >> >> No. People have to provide explicit permission to expose their email >> address. Otherwise the best we have are @ mentions in a comment. >> >> >> Aren't all active committer subscribed to this mailing list? >> > > They should be. Doesn't mean they pay attention to it. ;) > > -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: From brett at python.org Mon May 14 14:26:47 2018 From: brett at python.org (Brett Cannon) Date: Mon, 14 May 2018 14:26:47 -0400 Subject: [python-committers] Orphaned backports In-Reply-To: References: <2dac841a-881f-40b6-646a-674459fe0cc1@udel.edu> <48cb8f3c-59c0-ad20-33b7-a78cb557b805@gmail.com> Message-ID: On Mon, 14 May 2018 at 14:22 Mariatta Wijaya wrote: > To help with this, miss-islington will now assign the PR where backport > had failed to the core dev who merged the original PR. > Great feature! -Brett > > > Mariatta > > On Tue, Apr 24, 2018 at 8:57 AM, Brett Cannon wrote: > >> >> >> On Tue, 24 Apr 2018 at 02:59 Serhiy Storchaka >> wrote: >> >>> 23.04.18 19:47, Brett Cannon ????: >>> >>> On Sun, 22 Apr 2018 at 11:27 Terry Reedy wrote: >>> >>>> Does github allow repository owners to send email directly to people >>>> who >>>> have submitted PRs or at least, people with commit privileges (in this >>>> case, those whose have done particular merges)? >>>> >>> >>> No. People have to provide explicit permission to expose their email >>> address. Otherwise the best we have are @ mentions in a comment. >>> >>> >>> Aren't all active committer subscribed to this mailing list? >>> >> >> They should be. Doesn't mean they pay attention to it. ;) >> >> -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: From larry at hastings.org Mon May 14 16:41:00 2018 From: larry at hastings.org (Larry Hastings) Date: Mon, 14 May 2018 16:41:00 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer Message-ID: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Dr. Mark Shannon contributed the "key sharing dictionary" to Python, writing both the PEP and the implementation.? This shipped in Python 3.3 and was listed as one of the top features of that release as according to the "What's New?" document. We've asked Mark in the past if he'd be interested in becoming a core developer--and he actually said no.? At the time he said he didn't like our antiquated workflow.? Now that we've switched to the git-based core dev workflow, this objection is gone, and he's now interested in accepting the commit bit and the responsibilities that it entails. I suspect you, my colleagues in CPython core development, will be surprised at the current state of affairs.? I'm expecting a load of "you mean Mark *isn't* a core developer yet?" replies. Submitted for your consideration, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Mon May 14 16:42:50 2018 From: antoine at python.org (Antoine Pitrou) Date: Mon, 14 May 2018 22:42:50 +0200 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: +1. Regards Antoine. Le 14/05/2018 ? 22:41, Larry Hastings a ?crit?: > > > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, > writing both the PEP and the implementation.? This shipped in Python 3.3 > and was listed as one of the top features of that release as according > to the "What's New?" document. > > We've asked Mark in the past if he'd be interested in becoming a core > developer--and he actually said no.? At the time he said he didn't like > our antiquated workflow.? Now that we've switched to the git-based core > dev workflow, this objection is gone, and he's now interested in > accepting the commit bit and the responsibilities that it entails. > > I suspect you, my colleagues in CPython core development, will be > surprised at the current state of affairs.? I'm expecting a load of "you > mean Mark *isn't* a core developer yet?" replies. > > > Submitted for your consideration, > > > //arry/ > > > _______________________________________________ > 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 tim.peters at gmail.com Mon May 14 16:44:30 2018 From: tim.peters at gmail.com (Tim Peters) Date: Mon, 14 May 2018 15:44:30 -0500 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: +1 From eric at trueblade.com Mon May 14 16:44:53 2018 From: eric at trueblade.com (Eric V. Smith) Date: Mon, 14 May 2018 16:44:53 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: +1 Eric On 5/14/18 4:41 PM, Larry Hastings wrote: > > > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, > writing both the PEP and the implementation. This shipped in Python 3.3 > and was listed as one of the top features of that release as according > to the "What's New?" document. > > We've asked Mark in the past if he'd be interested in becoming a core > developer--and he actually said no. At the time he said he didn't like > our antiquated workflow. Now that we've switched to the git-based core > dev workflow, this objection is gone, and he's now interested in > accepting the commit bit and the responsibilities that it entails. > > I suspect you, my colleagues in CPython core development, will be > surprised at the current state of affairs. I'm expecting a load of "you > mean Mark *isn't* a core developer yet?" replies. > > > Submitted for your consideration, > > > //arry/ > > > _______________________________________________ > 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 guido at python.org Mon May 14 17:12:30 2018 From: guido at python.org (Guido van Rossum) Date: Mon, 14 May 2018 17:12:30 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: +2 On Mon, May 14, 2018 at 4:44 PM, Eric V. Smith wrote: > +1 > > Eric > > On 5/14/18 4:41 PM, Larry Hastings wrote: > >> >> >> Dr. Mark Shannon contributed the "key sharing dictionary" to Python, >> writing both the PEP and the implementation. This shipped in Python 3.3 >> and was listed as one of the top features of that release as according >> to the "What's New?" document. >> >> We've asked Mark in the past if he'd be interested in becoming a core >> developer--and he actually said no. At the time he said he didn't like >> our antiquated workflow. Now that we've switched to the git-based core >> dev workflow, this objection is gone, and he's now interested in >> accepting the commit bit and the responsibilities that it entails. >> >> I suspect you, my colleagues in CPython core development, will be >> surprised at the current state of affairs. I'm expecting a load of "you >> mean Mark *isn't* a core developer yet?" replies. >> >> >> Submitted for your consideration, >> >> >> //arry/ >> >> >> _______________________________________________ >> 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/ > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Mon May 14 17:18:13 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Mon, 14 May 2018 14:18:13 -0700 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: <5AF9FD15.6060408@stoneleaf.us> On 05/14/2018 01:41 PM, Larry Hastings wrote: > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, writing both the PEP and the implementation. This > shipped in Python 3.3 and was listed as one of the top features of that release as according to the "What's New?" document. > > We've asked Mark in the past if he'd be interested in becoming a core developer--and he actually said no. At the time > he said he didn't like our antiquated workflow. Now that we've switched to the git-based core dev workflow, this > objection is gone, and he's now interested in accepting the commit bit and the responsibilities that it entails. +1 -- ~Ethan~ From ericsnowcurrently at gmail.com Mon May 14 17:42:59 2018 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Mon, 14 May 2018 17:42:59 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: +1 -eric On Mon, May 14, 2018 at 4:41 PM, Larry Hastings wrote: > > > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, writing > both the PEP and the implementation. This shipped in Python 3.3 and was > listed as one of the top features of that release as according to the > "What's New?" document. > > We've asked Mark in the past if he'd be interested in becoming a core > developer--and he actually said no. At the time he said he didn't like our > antiquated workflow. Now that we've switched to the git-based core dev > workflow, this objection is gone, and he's now interested in accepting the > commit bit and the responsibilities that it entails. > > I suspect you, my colleagues in CPython core development, will be surprised > at the current state of affairs. I'm expecting a load of "you mean Mark > *isn't* a core developer yet?" replies. > > > Submitted for your consideration, > > > /arry > > _______________________________________________ > 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 levkivskyi at gmail.com Mon May 14 17:55:17 2018 From: levkivskyi at gmail.com (Ivan Levkivskyi) Date: Mon, 14 May 2018 17:55:17 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: +1 Yes, I actually thought he is a core dev for ages :-) -- Ivan On 14 May 2018 at 17:42, Eric Snow wrote: > +1 > > -eric > > On Mon, May 14, 2018 at 4:41 PM, Larry Hastings > wrote: > > > > > > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, > writing > > both the PEP and the implementation. This shipped in Python 3.3 and was > > listed as one of the top features of that release as according to the > > "What's New?" document. > > > > We've asked Mark in the past if he'd be interested in becoming a core > > developer--and he actually said no. At the time he said he didn't like > our > > antiquated workflow. Now that we've switched to the git-based core dev > > workflow, this objection is gone, and he's now interested in accepting > the > > commit bit and the responsibilities that it entails. > > > > I suspect you, my colleagues in CPython core development, will be > surprised > > at the current state of affairs. I'm expecting a load of "you mean Mark > > *isn't* a core developer yet?" replies. > > > > > > Submitted for your consideration, > > > > > > /arry > > > > _______________________________________________ > > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbk at shore.net Mon May 14 18:10:59 2018 From: kbk at shore.net (Kurt B. Kaiser) Date: Mon, 14 May 2018 18:10:59 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: <1526335859.430437.1372009008.7984E42C@webmail.messagingengine.com> +1 On Mon, May 14, 2018, at 4:41 PM, Larry Hastings wrote: > > > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, > writing both the PEP and the implementation.? This shipped in Python 3.3 > and was listed as one of the top features of that release as according > to the "What's New?" document. > > We've asked Mark in the past if he'd be interested in becoming a core > developer--and he actually said no.? At the time he said he didn't like > our antiquated workflow.? Now that we've switched to the git-based core > dev workflow, this objection is gone, and he's now interested in > accepting the commit bit and the responsibilities that it entails. > > I suspect you, my colleagues in CPython core development, will be > surprised at the current state of affairs.? I'm expecting a load of "you > mean Mark *isn't* a core developer yet?" replies. > > > Submitted for your consideration, > > > //arry/ > _______________________________________________ > 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 p.f.moore at gmail.com Mon May 14 18:32:30 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 14 May 2018 23:32:30 +0100 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: +1 from me :-) On 14 May 2018 at 21:41, Larry Hastings wrote: > > > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, writing > both the PEP and the implementation. This shipped in Python 3.3 and was > listed as one of the top features of that release as according to the > "What's New?" document. > > We've asked Mark in the past if he'd be interested in becoming a core > developer--and he actually said no. At the time he said he didn't like our > antiquated workflow. Now that we've switched to the git-based core dev > workflow, this objection is gone, and he's now interested in accepting the > commit bit and the responsibilities that it entails. > > I suspect you, my colleagues in CPython core development, will be surprised > at the current state of affairs. I'm expecting a load of "you mean Mark > *isn't* a core developer yet?" replies. > > > Submitted for your consideration, > > > /arry > > _______________________________________________ > 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 songofacandy at gmail.com Mon May 14 18:13:41 2018 From: songofacandy at gmail.com (INADA Naoki) Date: Tue, 15 May 2018 07:13:41 +0900 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: +1 2018?5?15?(?) 6:55 Ivan Levkivskyi : > +1 > > Yes, I actually thought he is a core dev for ages :-) > Me too. > -- > Ivan > > > > On 14 May 2018 at 17:42, Eric Snow wrote: > >> +1 >> >> -eric >> >> On Mon, May 14, 2018 at 4:41 PM, Larry Hastings >> wrote: >> > >> > >> > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, >> writing >> > both the PEP and the implementation. This shipped in Python 3.3 and was >> > listed as one of the top features of that release as according to the >> > "What's New?" document. >> > >> > We've asked Mark in the past if he'd be interested in becoming a core >> > developer--and he actually said no. At the time he said he didn't like >> our >> > antiquated workflow. Now that we've switched to the git-based core dev >> > workflow, this objection is gone, and he's now interested in accepting >> the >> > commit bit and the responsibilities that it entails. >> > >> > I suspect you, my colleagues in CPython core development, will be >> surprised >> > at the current state of affairs. I'm expecting a load of "you mean Mark >> > *isn't* a core developer yet?" replies. >> > >> > >> > Submitted for your consideration, >> > >> > >> > /arry >> > >> > _______________________________________________ >> > 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/ >> > > _______________________________________________ > 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: From storchaka at gmail.com Mon May 14 18:45:00 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Tue, 15 May 2018 01:45:00 +0300 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: <1a0517d7-5763-d1f9-84b0-c8725d73ebc3@gmail.com> 14.05.18 23:41, Larry Hastings ????: > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, > writing both the PEP and the implementation.? This shipped in Python > 3.3 and was listed as one of the top features of that release as > according to the "What's New?" document. > > We've asked Mark in the past if he'd be interested in becoming a core > developer--and he actually said no.? At the time he said he didn't > like our antiquated workflow.? Now that we've switched to the > git-based core dev workflow, this objection is gone, and he's now > interested in accepting the commit bit and the responsibilities that > it entails. > > I suspect you, my colleagues in CPython core development, will be > surprised at the current state of affairs.? I'm expecting a load of > "you mean Mark *isn't* a core developer yet?" replies. +1 from me. I always wondered why he is not a core developer. From willingc at gmail.com Mon May 14 18:58:36 2018 From: willingc at gmail.com (Carol Willing) Date: Mon, 14 May 2018 18:58:36 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: +1 On Mon, May 14, 2018, 6:47 PM INADA Naoki wrote: > +1 > > 2018?5?15?(?) 6:55 Ivan Levkivskyi : > >> +1 >> >> Yes, I actually thought he is a core dev for ages :-) >> > > Me too. > > >> -- >> Ivan >> >> >> >> On 14 May 2018 at 17:42, Eric Snow wrote: >> >>> +1 >>> >>> -eric >>> >>> On Mon, May 14, 2018 at 4:41 PM, Larry Hastings >>> wrote: >>> > >>> > >>> > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, >>> writing >>> > both the PEP and the implementation. This shipped in Python 3.3 and >>> was >>> > listed as one of the top features of that release as according to the >>> > "What's New?" document. >>> > >>> > We've asked Mark in the past if he'd be interested in becoming a core >>> > developer--and he actually said no. At the time he said he didn't >>> like our >>> > antiquated workflow. Now that we've switched to the git-based core dev >>> > workflow, this objection is gone, and he's now interested in accepting >>> the >>> > commit bit and the responsibilities that it entails. >>> > >>> > I suspect you, my colleagues in CPython core development, will be >>> surprised >>> > at the current state of affairs. I'm expecting a load of "you mean >>> Mark >>> > *isn't* a core developer yet?" replies. >>> > >>> > >>> > Submitted for your consideration, >>> > >>> > >>> > /arry >>> > >>> > _______________________________________________ >>> > 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/ >>> >> >> _______________________________________________ >> 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yselivanov.ml at gmail.com Mon May 14 20:30:45 2018 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Mon, 14 May 2018 20:30:45 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: +1 Yury -- Yury -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukasz at langa.pl Mon May 14 20:33:18 2018 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Mon, 14 May 2018 20:33:18 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: +1 -- Best regards, ?ukasz Langa > On May 14, 2018, at 4:41 PM, Larry Hastings wrote: > > > > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, writing both the PEP and the implementation. This shipped in Python 3.3 and was listed as one of the top features of that release as according to the "What's New?" document. > > We've asked Mark in the past if he'd be interested in becoming a core developer--and he actually said no. At the time he said he didn't like our antiquated workflow. Now that we've switched to the git-based core dev workflow, this objection is gone, and he's now interested in accepting the commit bit and the responsibilities that it entails. > > I suspect you, my colleagues in CPython core development, will be surprised at the current state of affairs. I'm expecting a load of "you mean Mark *isn't* a core developer yet?" replies. > > > Submitted for your consideration, > > > /arry > _______________________________________________ > 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: From christian at python.org Mon May 14 21:38:05 2018 From: christian at python.org (Christian Heimes) Date: Mon, 14 May 2018 21:38:05 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: <4c9f3924-fcf4-ceef-d475-35cc6bf166f5@python.org> On 2018-05-14 16:41, Larry Hastings wrote: > > > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, > writing both the PEP and the implementation.? This shipped in Python 3.3 > and was listed as one of the top features of that release as according > to the "What's New?" document. > > We've asked Mark in the past if he'd be interested in becoming a core > developer--and he actually said no.? At the time he said he didn't like > our antiquated workflow.? Now that we've switched to the git-based core > dev workflow, this objection is gone, and he's now interested in > accepting the commit bit and the responsibilities that it entails. > > I suspect you, my colleagues in CPython core development, will be > surprised at the current state of affairs.? I'm expecting a load of "you > mean Mark *isn't* a core developer yet?" replies. > +1 From eric at trueblade.com Mon May 14 21:49:36 2018 From: eric at trueblade.com (Eric V. Smith) Date: Mon, 14 May 2018 21:49:36 -0400 Subject: [python-committers] AppVeyor and Travis-CI Message-ID: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> I accidentally checked in some test files, and they got backported to 3.7. I pushed a commit to delete them, and it was committed to master. But in the 3.7 backport, something has gone wrong with AppVeyor and Travis-CI. https://github.com/python/cpython/pull/6844 AppVeyor says "Expected ? Waiting for status to be reported". There's no obvious way to get it to actually report the status, or to restart. There is no "Details" button listed on the PR page. For Travis-CI, Miss Isslington sent me an email that says "Backport status check is done, and it's a failure ? ." The Travis-CI log file ends with a timeout: ====================================================================== FAIL: test_stdin_broken_pipe (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py", line 214, in test_stdin_broken_pipe self.loop.run_until_complete, coro) AssertionError: (, ) not raised by run_until_complete ---------------------------------------------------------------------- I'm sure this is all due to the heavy load the systems are under. I can't find a way to kick both of these off again. I couldn't find anything in the devguide, but if I missed it please let me know. Thanks. Eric From tjreedy at udel.edu Mon May 14 23:36:07 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 14 May 2018 23:36:07 -0400 Subject: [python-committers] AppVeyor and Travis-CI In-Reply-To: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> Message-ID: <4a843ab2-2c2f-b490-bebc-02cf5bcb8bb4@udel.edu> On 5/14/2018 9:49 PM, Eric V. Smith wrote: > I accidentally checked in some test files, and they got backported to > 3.7. I pushed a commit to delete them, and it was committed to master. > > But in the 3.7 backport, something has gone wrong with AppVeyor and > Travis-CI. > > https://github.com/python/cpython/pull/6844 > > AppVeyor says "Expected ? Waiting for status to be reported". There's no > obvious way to get it to actually report the status, or to restart. > There is no "Details" button listed on the PR page. > > For Travis-CI, Miss Isslington sent me an email that says "Backport > status check is done, and it's a failure ? ." The Travis-CI log file > ends with a timeout: > > ====================================================================== > FAIL: test_stdin_broken_pipe > (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) > ---------------------------------------------------------------------- > Traceback (most recent call last): > ? File > "/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py", > line 214, in test_stdin_broken_pipe > ??? self.loop.run_until_complete, coro) > AssertionError: (, 'ConnectionResetError'>) not raised by run_until_complete > ---------------------------------------------------------------------- > > I'm sure this is all due to the heavy load the systems are under. I > can't find a way to kick both of these off again. I couldn't find > anything in the devguide, but if I missed it please let me know. I have triggered retesting by editing the blurb. It may be that touching by adding and deleting a space was enough, or maybe I had to actually change something. But retesting right now, with tests failing, is useless. I just submitting a trivial change and got the same unrelated failures for importlib, multiprocessing, and asyncio. Warning -- files was modified by test_importlib Before: [] After: ['core'] ERROR: test_ignore (test.test_multiprocessing_forkserver.TestIgnoreEINTR) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/travis/build/python/cpython/Lib/test/_test_multiprocessing.py", line 4359, in test_ignore os.kill(p.pid, signal.SIGUSR1) ProcessLookupError: [Errno 3] No such process ---------------------------------------------------------------------- Ran 310 tests in 93.862s FAILED (errors=1, skipped=27) test test_multiprocessing_forkserver failed and the same or similar multiple failures for asyncio Both our tests ended with FAILED (failures=2, skipped=14) test test_asyncio failed 2 tests failed again: test_asyncio test_multiprocessing_forkserver Total duration: 14 min 29 sec Tests result: FAILURE and we cannot merge. From vstinner at redhat.com Tue May 15 00:27:19 2018 From: vstinner at redhat.com (Victor Stinner) Date: Tue, 15 May 2018 00:27:19 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: 2018-05-14 16:41 GMT-04:00 Larry Hastings : > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, writing > both the PEP and the implementation. This shipped in Python 3.3 and was > listed as one of the top features of that release as according to the > "What's New?" document. > > We've asked Mark in the past if he'd be interested in becoming a core > developer--and he actually said no. At the time he said he didn't like our > antiquated workflow. Now that we've switched to the git-based core dev > workflow, this objection is gone, and he's now interested in accepting the > commit bit and the responsibilities that it entails. > > I suspect you, my colleagues in CPython core development, will be surprised > at the current state of affairs. I'm expecting a load of "you mean Mark > *isn't* a core developer yet?" replies. Wait. Mark is already a core dev, right? I don't understand your email :-) +1, obvisouly. Victor From nad at python.org Tue May 15 07:51:52 2018 From: nad at python.org (Ned Deily) Date: Tue, 15 May 2018 07:51:52 -0400 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! Message-ID: This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release candidate. Our goal continues been to be to have no changes between the release candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Those of us who are participating in the development sprints at PyCon US 2018 here in Cleveland can feel the excitement building as we work through the remaining issues, including completing the "What's New in 3.7" document and final feature documentation. (We wish you could all be here.) As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You should now be treating the 3.7 branch as if it were already released and in maintenance mode. That means you should only push the kinds of changes that are appropriate for a maintenance release: non-ABI-changing bug and feature fixes and documentation updates. If you find a problem that requires an ABI-altering or other significant user-facing change (for example, something likely to introduce an incompatibility with existing users' code or require rebuilding of user extension modules), please make sure to set the b.p.o issue to "release blocker" priority and describe there why you feel the change is necessary. If you are reviewing PRs for 3.7 (and please do!), be on the lookout for and flag potential incompatibilities (we've all made them). Thanks again for all of your hard work towards making 3.7.0 yet another great release - coming to a website near you on 06-15! Release Managerly Yours, --Ned https://www.python.org/dev/peps/pep-0537/ -- Ned Deily nad at python.org -- [] From andrew.svetlov at gmail.com Tue May 15 08:43:05 2018 From: andrew.svetlov at gmail.com (Andrew Svetlov) Date: Tue, 15 May 2018 15:43:05 +0300 Subject: [python-committers] Idea: Create subteams? In-Reply-To: References: Message-ID: Agree with Yuri. We have not big amount of non-committer contributions into asyncio, and every non-trivial change requires very careful review. On Thu, Apr 26, 2018, 17:32 Yury Selivanov wrote: > On Thu, Apr 26, 2018 at 10:12 AM Victor Stinner > wrote: > [..] > > I identified 3 obvious subteams: > > > * Documentation > > * IDLE > > * asyncio > > Sorry, asyncio isn't an obvious choice for me. There are not so many > low-hanging fruits left in asyncio except improvements to its > documentation. I'm a firm -1 to allow people to merge without Andrew's or > my review at this point, almost no PRs are fine when they are submitted > (including our own). There's a lot of complexity in asyncio which isn't > immediately evident to people who are not working with its internals on a > daily basis. > > Now, people who report and submit asyncio PRs seem to do that just fine > without subteams. Although it's rare to see people contributing more than > once, but that's not an asyncio-specific pattern, I see it in every big and > complex project I happen to contribute to. Even having a dedicated asyncio > mailing list doesn't help to get people to contribute to asyncio more > frequently. > > Don't get me wrong, Andrew and I would certainly welcome any help we can > get, but I'd be against running a public experiment with asyncio to see if > 2 of us can handle the management of the new sub-teams idea. Unfortunately > 2 of us just don't have capacity for that. > > Please pick another project for your idea. Maybe we should try it for > documentation first, where we have a lot of core devs who can help with PR > reviews and management of "subteams". > > Yury > _______________________________________________ > 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/ > -- Thanks, Andrew Svetlov -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Tue May 15 11:34:37 2018 From: guido at python.org (Guido van Rossum) Date: Tue, 15 May 2018 11:34:37 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: Let's stop the email barrage, Mark is in. Can someone tell Mark what to do? On Tue, May 15, 2018 at 12:27 AM, Victor Stinner wrote: > 2018-05-14 16:41 GMT-04:00 Larry Hastings : > > Dr. Mark Shannon contributed the "key sharing dictionary" to Python, > writing > > both the PEP and the implementation. This shipped in Python 3.3 and was > > listed as one of the top features of that release as according to the > > "What's New?" document. > > > > We've asked Mark in the past if he'd be interested in becoming a core > > developer--and he actually said no. At the time he said he didn't like > our > > antiquated workflow. Now that we've switched to the git-based core dev > > workflow, this objection is gone, and he's now interested in accepting > the > > commit bit and the responsibilities that it entails. > > > > I suspect you, my colleagues in CPython core development, will be > surprised > > at the current state of affairs. I'm expecting a load of "you mean Mark > > *isn't* a core developer yet?" replies. > > Wait. Mark is already a core dev, right? I don't understand your email :-) > > +1, obvisouly. > > 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/ > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at trueblade.com Tue May 15 11:35:58 2018 From: eric at trueblade.com (Eric V. Smith) Date: Tue, 15 May 2018 11:35:58 -0400 Subject: [python-committers] AppVeyor and Travis-CI In-Reply-To: References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> Message-ID: Thanks. You mean close and re-open the bpo issue? In the past I saw a Travis "re-run" button, but now I don't. I expected to see it on the Travis page, but last night I only saw a "More options" menu and no "re-run". The next time something fails I'll look again. On 5/15/18 11:23 AM, Brett Cannon wrote: > You can always close and then open an issue to re-trigger CI. As for > Travis specifically, you should have the proper permissions to forcibly > re-run the builds. > > On Mon, 14 May 2018 at 21:50 Eric V. Smith > wrote: > > I accidentally checked in some test files, and they got backported to > 3.7. I pushed a commit to delete them, and it was committed to master. > > But in the 3.7 backport, something has gone wrong with AppVeyor and > Travis-CI. > > https://github.com/python/cpython/pull/6844 > > AppVeyor says "Expected ? Waiting for status to be reported". > There's no > obvious way to get it to actually report the status, or to restart. > There is no "Details" button listed on the PR page. > > For Travis-CI, Miss Isslington sent me an email that says "Backport > status check is done, and it's a failure ? ." The Travis-CI log file > ends with a timeout: > > ====================================================================== > FAIL: test_stdin_broken_pipe > (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py", > > line 214, in test_stdin_broken_pipe > self.loop.run_until_complete, coro) > AssertionError: (, 'ConnectionResetError'>) not raised by run_until_complete > ---------------------------------------------------------------------- > > I'm sure this is all due to the heavy load the systems are under. I > can't find a way to kick both of these off again. I couldn't find > anything in the devguide, but if I missed it please let me know. > > Thanks. > Eric > _______________________________________________ > 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 brett at python.org Tue May 15 11:23:00 2018 From: brett at python.org (Brett Cannon) Date: Tue, 15 May 2018 11:23:00 -0400 Subject: [python-committers] AppVeyor and Travis-CI In-Reply-To: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> Message-ID: You can always close and then open an issue to re-trigger CI. As for Travis specifically, you should have the proper permissions to forcibly re-run the builds. On Mon, 14 May 2018 at 21:50 Eric V. Smith wrote: > I accidentally checked in some test files, and they got backported to > 3.7. I pushed a commit to delete them, and it was committed to master. > > But in the 3.7 backport, something has gone wrong with AppVeyor and > Travis-CI. > > https://github.com/python/cpython/pull/6844 > > AppVeyor says "Expected ? Waiting for status to be reported". There's no > obvious way to get it to actually report the status, or to restart. > There is no "Details" button listed on the PR page. > > For Travis-CI, Miss Isslington sent me an email that says "Backport > status check is done, and it's a failure ? ." The Travis-CI log file > ends with a timeout: > > ====================================================================== > FAIL: test_stdin_broken_pipe > (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py", > > line 214, in test_stdin_broken_pipe > self.loop.run_until_complete, coro) > AssertionError: (, 'ConnectionResetError'>) not raised by run_until_complete > ---------------------------------------------------------------------- > > I'm sure this is all due to the heavy load the systems are under. I > can't find a way to kick both of these off again. I couldn't find > anything in the devguide, but if I missed it please let me know. > > Thanks. > Eric > _______________________________________________ > 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: From guido at python.org Tue May 15 14:02:56 2018 From: guido at python.org (Guido van Rossum) Date: Tue, 15 May 2018 14:02:56 -0400 Subject: [python-committers] AppVeyor and Travis-CI In-Reply-To: References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> Message-ID: IIUC you have to close and reopen the PR. On Tue, May 15, 2018 at 11:35 AM, Eric V. Smith wrote: > Thanks. You mean close and re-open the bpo issue? > > In the past I saw a Travis "re-run" button, but now I don't. I expected to > see it on the Travis page, but last night I only saw a "More options" menu > and no "re-run". The next time something fails I'll look again. > > On 5/15/18 11:23 AM, Brett Cannon wrote: > >> You can always close and then open an issue to re-trigger CI. As for >> Travis specifically, you should have the proper permissions to forcibly >> re-run the builds. >> >> On Mon, 14 May 2018 at 21:50 Eric V. Smith > > wrote: >> >> I accidentally checked in some test files, and they got backported to >> 3.7. I pushed a commit to delete them, and it was committed to master. >> >> But in the 3.7 backport, something has gone wrong with AppVeyor and >> Travis-CI. >> >> https://github.com/python/cpython/pull/6844 >> >> AppVeyor says "Expected ? Waiting for status to be reported". >> There's no >> obvious way to get it to actually report the status, or to restart. >> There is no "Details" button listed on the PR page. >> >> For Travis-CI, Miss Isslington sent me an email that says "Backport >> status check is done, and it's a failure ? ." The Travis-CI log file >> ends with a timeout: >> >> ============================================================ >> ========== >> FAIL: test_stdin_broken_pipe >> (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) >> ------------------------------------------------------------ >> ---------- >> Traceback (most recent call last): >> File >> "/home/travis/build/python/cpython/Lib/test/test_asyncio/tes >> t_subprocess.py", >> >> line 214, in test_stdin_broken_pipe >> self.loop.run_until_complete, coro) >> AssertionError: (, > 'ConnectionResetError'>) not raised by run_until_complete >> ------------------------------------------------------------ >> ---------- >> >> I'm sure this is all due to the heavy load the systems are under. I >> can't find a way to kick both of these off again. I couldn't find >> anything in the devguide, but if I missed it please let me know. >> >> Thanks. >> Eric >> _______________________________________________ >> 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/ > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Tue May 15 16:36:33 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 15 May 2018 16:36:33 -0400 Subject: [python-committers] AppVeyor and Travis-CI In-Reply-To: References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> Message-ID: I am getting repeated bogus failures, completely unrelated to a trivial patch, more often than not, on Travis-CI For instance, https://travis-ci.org/python/cpython/jobs/379349709 2 tests failed: test_asyncio test_multiprocessing_forkserver 1 test altered the execution environment: test_importlib The failures repeated on retest. Can someone turn off the bad test methods? tjr From mariatta.wijaya at gmail.com Tue May 15 16:51:24 2018 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Tue, 15 May 2018 16:51:24 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: Part of the new core dev initiation should be watching this talk, titled "What is a Python Core Developer?" https://youtu.be/hhj7eb6TrtI On Tue, May 15, 2018, 11:35 AM Guido van Rossum wrote: > Let's stop the email barrage, Mark is in. Can someone tell Mark what to do? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Tue May 15 17:01:19 2018 From: guido at python.org (Guido van Rossum) Date: Tue, 15 May 2018 17:01:19 -0400 Subject: [python-committers] Proposing Mark Shannon to be a core developer In-Reply-To: References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org> Message-ID: Thanks Mariatta! It would also be nice if we gave new committers a task along the lines of "mentor one woman or other person of diversity through their first non-trivial PR". (If the new committer is not comfortable actually merging the PR they can ask a more experienced core dev to do that -- after all new core devs are supposed to be mentored themselves by a more experienced core dev.) Even nicer would be if *every* core dev made a commitment to "sponsor" at least one person of diversity. I understand not everyone has the time. But perhaps *some* core devs will volunteer! Increasing the core's diversity is a very important goal to ensure the future health of Python. On Tue, May 15, 2018 at 4:51 PM, Mariatta Wijaya wrote: > Part of the new core dev initiation should be watching this talk, titled > "What is a Python Core Developer?" https://youtu.be/hhj7eb6TrtI > > On Tue, May 15, 2018, 11:35 AM Guido van Rossum wrote: > >> Let's stop the email barrage, Mark is in. Can someone tell Mark what to >> do? >> >> -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Wed May 16 02:22:52 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 16 May 2018 02:22:52 -0400 Subject: [python-committers] AppVeyor and Travis-CI In-Reply-To: References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> Message-ID: It seems like the job has been rescheduled. I cannot see the failure ("394 tests OK"). Would you mind to open a bug report? Do you only see these failures in the 3.6 branch? Victor 2018-05-15 16:36 GMT-04:00 Terry Reedy : > I am getting repeated bogus failures, completely unrelated to a trivial > patch, more often than not, on Travis-CI > For instance, > https://travis-ci.org/python/cpython/jobs/379349709 > 2 tests failed: > test_asyncio test_multiprocessing_forkserver > 1 test altered the execution environment: > test_importlib > > The failures repeated on retest. Can someone turn off the bad test methods? > > tjr > > _______________________________________________ > 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 vstinner at redhat.com Wed May 16 02:31:16 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 16 May 2018 02:31:16 -0400 Subject: [python-committers] AppVeyor and Travis-CI In-Reply-To: References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> Message-ID: Oh, maybe I saw them. Are you talking about: "test_multiprocessing_forkserver: TestIgnoreEINTR.test_ignore() fails on Travis CI" https://bugs.python.org/issue33531 "test_asyncio: test_subprocess test_stdin_broken_pipe() failure on Travis CI" https://bugs.python.org/issue33532 (I just created these two issues.) Victor 2018-05-16 2:22 GMT-04:00 Victor Stinner : > It seems like the job has been rescheduled. I cannot see the failure > ("394 tests OK"). Would you mind to open a bug report? > > Do you only see these failures in the 3.6 branch? > > Victor > > 2018-05-15 16:36 GMT-04:00 Terry Reedy : >> I am getting repeated bogus failures, completely unrelated to a trivial >> patch, more often than not, on Travis-CI >> For instance, >> https://travis-ci.org/python/cpython/jobs/379349709 >> 2 tests failed: >> test_asyncio test_multiprocessing_forkserver >> 1 test altered the execution environment: >> test_importlib >> >> The failures repeated on retest. Can someone turn off the bad test methods? >> >> tjr >> >> _______________________________________________ >> 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 tjreedy at udel.edu Wed May 16 02:42:03 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 16 May 2018 02:42:03 -0400 Subject: [python-committers] AppVeyor and Travis-CI In-Reply-To: References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> Message-ID: <05e2e96b-0674-f92d-c8bf-87e19ea2a980@udel.edu> On 5/16/2018 2:31 AM, Victor Stinner wrote: > Oh, maybe I saw them. Are you talking about: > > "test_multiprocessing_forkserver: TestIgnoreEINTR.test_ignore() fails > on Travis CI" > https://bugs.python.org/issue33531 > > "test_asyncio: test_subprocess test_stdin_broken_pipe() failure on Travis CI" > https://bugs.python.org/issue33532 > > (I just created these two issues.) Those are the two test files that failed, though I believe there were more test methods that failed in test_asyncio. > 2018-05-16 2:22 GMT-04:00 Victor Stinner : >> It seems like the job has been rescheduled. I later restarted just the Travis test, so as to not toss the OK Appveyor test and have to wait another 4 hours to get it to pass again. I cannot see the failure >> ("394 tests OK"). Would you mind to open a bug report? >> >> Do you only see these failures in the 3.6 branch? No. However, it happened again on my next 3.6 only patch. I restarted just Travis and it passed. The failure rate the last 24 hours has been about 1/3. >> 2018-05-15 16:36 GMT-04:00 Terry Reedy : >>> I am getting repeated bogus failures, completely unrelated to a trivial >>> patch, more often than not, on Travis-CI >>> For instance, >>> https://travis-ci.org/python/cpython/jobs/379349709 >>> 2 tests failed: >>> test_asyncio test_multiprocessing_forkserver >>> 1 test altered the execution environment: >>> test_importlib >>> >>> The failures repeated on retest. Can someone turn off the bad test methods? From eric at trueblade.com Wed May 16 07:31:09 2018 From: eric at trueblade.com (Eric V. Smith) Date: Wed, 16 May 2018 07:31:09 -0400 Subject: [python-committers] AppVeyor and Travis-CI In-Reply-To: References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> Message-ID: <3194174d-68f3-f1ad-b365-e3ec5cc0b8a2@trueblade.com> That's very helpful, thanks. The issue was that I wasn't logged on to Travis. I didn't know that was a thing. I'll check and see if this info is in the devguide. Eric On 5/15/18 12:20 PM, Alex Gaynor wrote: > FWIW, attached is an image pointing out the re-run button. If you're > not seeing those it means either a) you're not logged into Travis, b) > somehow it's not picking up your permissions correctly. > > Alex > > On Tue, May 15, 2018 at 11:36 AM Eric V. Smith > wrote: > > Thanks. You mean close and re-open the bpo issue? > > In the past I saw a Travis "re-run" button, but now I don't. I > expected > to see it on the Travis page, but last night I only saw a "More > options" > menu and no "re-run". The next time something fails I'll look again. > > On 5/15/18 11:23 AM, Brett Cannon wrote: > > You can always close and then open an issue to re-trigger CI. As for > > Travis specifically, you should have the proper permissions to > forcibly > > re-run the builds. > > > > On Mon, 14 May 2018 at 21:50 Eric V. Smith > > >> wrote: > > > > I accidentally checked in some test files, and they got > backported to > > 3.7. I pushed a commit to delete them, and it was committed > to master. > > > > But in the 3.7 backport, something has gone wrong with > AppVeyor and > > Travis-CI. > > > > https://github.com/python/cpython/pull/6844 > > > > AppVeyor says "Expected ? Waiting for status to be reported". > > There's no > > obvious way to get it to actually report the status, or to > restart. > > There is no "Details" button listed on the PR page. > > > > For Travis-CI, Miss Isslington sent me an email that says > "Backport > > status check is done, and it's a failure ? ." The Travis-CI > log file > > ends with a timeout: > > > > > ====================================================================== > > FAIL: test_stdin_broken_pipe > > (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) > > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File > > > "/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py", > > > > line 214, in test_stdin_broken_pipe > > self.loop.run_until_complete, coro) > > AssertionError: (, > 'ConnectionResetError'>) not raised by run_until_complete > > > ---------------------------------------------------------------------- > > > > I'm sure this is all due to the heavy load the systems are > under. I > > can't find a way to kick both of these off again. I couldn't > find > > anything in the devguide, but if I missed it please let me know. > > > > Thanks. > > Eric > > _______________________________________________ > > 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/ > > > > -- > "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: From alex.gaynor at gmail.com Tue May 15 12:20:33 2018 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Tue, 15 May 2018 12:20:33 -0400 Subject: [python-committers] AppVeyor and Travis-CI In-Reply-To: References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> Message-ID: FWIW, attached is an image pointing out the re-run button. If you're not seeing those it means either a) you're not logged into Travis, b) somehow it's not picking up your permissions correctly. Alex On Tue, May 15, 2018 at 11:36 AM Eric V. Smith wrote: > Thanks. You mean close and re-open the bpo issue? > > In the past I saw a Travis "re-run" button, but now I don't. I expected > to see it on the Travis page, but last night I only saw a "More options" > menu and no "re-run". The next time something fails I'll look again. > > On 5/15/18 11:23 AM, Brett Cannon wrote: > > You can always close and then open an issue to re-trigger CI. As for > > Travis specifically, you should have the proper permissions to forcibly > > re-run the builds. > > > > On Mon, 14 May 2018 at 21:50 Eric V. Smith > > wrote: > > > > I accidentally checked in some test files, and they got backported to > > 3.7. I pushed a commit to delete them, and it was committed to > master. > > > > But in the 3.7 backport, something has gone wrong with AppVeyor and > > Travis-CI. > > > > https://github.com/python/cpython/pull/6844 > > > > AppVeyor says "Expected ? Waiting for status to be reported". > > There's no > > obvious way to get it to actually report the status, or to restart. > > There is no "Details" button listed on the PR page. > > > > For Travis-CI, Miss Isslington sent me an email that says "Backport > > status check is done, and it's a failure ? ." The Travis-CI log file > > ends with a timeout: > > > > > ====================================================================== > > FAIL: test_stdin_broken_pipe > > (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) > > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File > > > "/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py", > > > > line 214, in test_stdin_broken_pipe > > self.loop.run_until_complete, coro) > > AssertionError: (, > 'ConnectionResetError'>) not raised by run_until_complete > > > ---------------------------------------------------------------------- > > > > I'm sure this is all due to the heavy load the systems are under. I > > can't find a way to kick both of these off again. I couldn't find > > anything in the devguide, but if I missed it please let me know. > > > > Thanks. > > Eric > > _______________________________________________ > > 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/ > -- "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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2018-05-15 at 12.19.02 PM.png Type: image/png Size: 102955 bytes Desc: not available URL: From brian at python.org Wed May 16 09:52:50 2018 From: brian at python.org (Brian Curtin) Date: Wed, 16 May 2018 09:52:50 -0400 Subject: [python-committers] Mentoring Office Hours - the idea, and a question Message-ID: Hey all, At the Language Summit last week, after Mariatta's talk we had a conversation around diversity and how to grow our contributor base, which led to someone (Steve Dower?) suggesting we post a sort of "Office Hours" list. This would be a list of current core developers who are interested in being available at set time(s) for helping mentor newer contributors in our community through our process and, if they're interested, mentoring them through the process of becoming core developers themselves. This "Office Hours" concept is a type of thing that has worked well elsewhere, including around the software world, and we have some people interested in offering said mentorship, so I would like to move on to getting this list up somewhere so we can start doing it. With that said, before I go make a PR to the devguide to start iterating on the implementation, an important question: As this is both an event similar to an in-person meetup and an event meant to be a safe space for those getting started, it will explicitly mention the code of conduct. As such, it needs a person/persons/list to contact should something arise in this context that needs to be handled. What/who should that be? * Suggestion 1: use the already in-place core-mentorship-owner at python.org, though I can't tell who's on there. * Suggestion 2: Create some new list with a few key people on it. * Suggestion 3: List some direct names. Who? As for implementation, there are some tools out there we could possibly use, but in the interests of getting something out there I'm just going to make a table and fill in some common information, starting with my own. Calendar apps and other integrations can come as we figure them out. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Wed May 16 11:31:26 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 16 May 2018 11:31:26 -0400 Subject: [python-committers] Mentoring Office Hours - the idea, and a question In-Reply-To: References: Message-ID: Hi, I'm usually available between 10:00 and 16:00 in the French timezone (currently, it's CEST = UTC+2). A few months ago, I wrote a tutorial and a list of available core developers... currently it's just me :-D http://cpython-core-tutorial.readthedocs.io/en/latest/getting_help.html Maybe this list should be moved in the developer guide? https://devguide.python.org/help/ I chose to put it in my tutorial, since it's less official, and I was not sure if I should put myself in the official guide ;-) -- I also heard the idea of pair-programming using a chat, a video conference, or something else. For example, when you work on a bug, do it with a contributor to show how you work. I never did that before, but I may try ;-) Victor 2018-05-16 9:52 GMT-04:00 Brian Curtin : > Hey all, > > At the Language Summit last week, after Mariatta's talk we had a > conversation around diversity and how to grow our contributor base, which > led to someone (Steve Dower?) suggesting we post a sort of "Office Hours" > list. This would be a list of current core developers who are interested in > being available at set time(s) for helping mentor newer contributors in our > community through our process and, if they're interested, mentoring them > through the process of becoming core developers themselves. > > This "Office Hours" concept is a type of thing that has worked well > elsewhere, including around the software world, and we have some people > interested in offering said mentorship, so I would like to move on to > getting this list up somewhere so we can start doing it. > > With that said, before I go make a PR to the devguide to start iterating on > the implementation, an important question: > > As this is both an event similar to an in-person meetup and an event meant > to be a safe space for those getting started, it will explicitly mention the > code of conduct. As such, it needs a person/persons/list to contact should > something arise in this context that needs to be handled. What/who should > that be? > * Suggestion 1: use the already in-place core-mentorship-owner at python.org, > though I can't tell who's on there. > * Suggestion 2: Create some new list with a few key people on it. > * Suggestion 3: List some direct names. Who? > > As for implementation, there are some tools out there we could possibly use, > but in the interests of getting something out there I'm just going to make a > table and fill in some common information, starting with my own. Calendar > apps and other integrations can come as we figure them out. > > Brian > > _______________________________________________ > 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 brian at python.org Wed May 16 11:50:13 2018 From: brian at python.org (Brian Curtin) Date: Wed, 16 May 2018 11:50:13 -0400 Subject: [python-committers] Mentoring Office Hours - the idea, and a question In-Reply-To: References: Message-ID: Yep, this is something I'm adding directly in the devguide so it's right where new contributors are already going to be looking for help and information. As for how those mentors and mentees actually do the work, to start with I think it's something that each person should just do what they're comfortable with and have access to, and then once we have some data to work off of, maybe then we prescribe some specific ways of doing it. I'm ok to do video things, but some might not be, so in getting this started I wanted to just begin with names, days, times, and contact information on an official website. If someone wants mentorship and they're available when I'm available, they reach out to me and we find a way to talk. On Wed, May 16, 2018 at 11:31 AM Victor Stinner wrote: > Hi, > > I'm usually available between 10:00 and 16:00 in the French timezone > (currently, it's CEST = UTC+2). > > A few months ago, I wrote a tutorial and a list of available core > developers... currently it's just me :-D > > http://cpython-core-tutorial.readthedocs.io/en/latest/getting_help.html > > Maybe this list should be moved in the developer guide? > > https://devguide.python.org/help/ > > I chose to put it in my tutorial, since it's less official, and I was > not sure if I should put myself in the official guide ;-) > > -- > > I also heard the idea of pair-programming using a chat, a video > conference, or something else. > > For example, when you work on a bug, do it with a contributor to show > how you work. I never did that before, but I may try ;-) > > Victor > > 2018-05-16 9:52 GMT-04:00 Brian Curtin : > > Hey all, > > > > At the Language Summit last week, after Mariatta's talk we had a > > conversation around diversity and how to grow our contributor base, which > > led to someone (Steve Dower?) suggesting we post a sort of "Office Hours" > > list. This would be a list of current core developers who are interested > in > > being available at set time(s) for helping mentor newer contributors in > our > > community through our process and, if they're interested, mentoring them > > through the process of becoming core developers themselves. > > > > This "Office Hours" concept is a type of thing that has worked well > > elsewhere, including around the software world, and we have some people > > interested in offering said mentorship, so I would like to move on to > > getting this list up somewhere so we can start doing it. > > > > With that said, before I go make a PR to the devguide to start iterating > on > > the implementation, an important question: > > > > As this is both an event similar to an in-person meetup and an event > meant > > to be a safe space for those getting started, it will explicitly mention > the > > code of conduct. As such, it needs a person/persons/list to contact > should > > something arise in this context that needs to be handled. What/who should > > that be? > > * Suggestion 1: use the already in-place > core-mentorship-owner at python.org, > > though I can't tell who's on there. > > * Suggestion 2: Create some new list with a few key people on it. > > * Suggestion 3: List some direct names. Who? > > > > As for implementation, there are some tools out there we could possibly > use, > > but in the interests of getting something out there I'm just going to > make a > > table and fill in some common information, starting with my own. Calendar > > apps and other integrations can come as we figure them out. > > > > Brian > > > > _______________________________________________ > > 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: From tjreedy at udel.edu Wed May 16 12:22:27 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 16 May 2018 12:22:27 -0400 Subject: [python-committers] AppVeyor and Travis-CI In-Reply-To: References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com> Message-ID: <2a5f268a-9d72-cd90-9a08-3a934654c2e2@udel.edu> On 5/15/2018 12:20 PM, Alex Gaynor wrote: > FWIW, attached is an image pointing out the re-run button. If you're not > seeing those it means either a) you're not logged into Travis, b) > somehow it's not picking up your permissions correctly. Is there anything in the devguide about this? The first time I tried to use a rebuild button, there was some sort of login/registration procedure. Since then, it just works when I am logged in to github. Thank you for the image. I did not know that the unlabeled symbols at the end of each line for the three sub-builds was a rerun button for the one sub-build. Good to know to only re-run what is needed. TJR From vstinner at redhat.com Wed May 16 18:08:36 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 16 May 2018 18:08:36 -0400 Subject: [python-committers] Mentoring Office Hours - the idea, and a question In-Reply-To: References: Message-ID: 2018-05-16 11:31 GMT-04:00 Victor Stinner : > I'm usually available between 10:00 and 16:00 in the French timezone > (currently, it's CEST = UTC+2). Oh, let me be more specific: 10:00-12:00 and 14:00-16:00, Monday to Friday Yeah, in France we take our time to eat ;-) Victor From steve.dower at python.org Wed May 16 18:09:29 2018 From: steve.dower at python.org (Steve Dower) Date: Wed, 16 May 2018 18:09:29 -0400 Subject: [python-committers] Visual Studio Team Services checks on pull requests Message-ID: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org> Hi all Just a quick note right now - don't have time for all the details. I'm experimenting with using Visual Studio Team Services to do builds of CPython. Right now, you'll probably see failed builds on all PRs while I get security options figured out. These *will not* block your PR, so feel free to ignore them. Apologies for the noise in the meantime. Cheers, STeve From steve.dower at python.org Wed May 16 18:27:26 2018 From: steve.dower at python.org (Steve Dower) Date: Wed, 16 May 2018 18:27:26 -0400 Subject: [python-committers] Visual Studio Team Services checks on pullrequests In-Reply-To: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org> References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org> Message-ID: And a quick follow up ? the builds should be running successfully now. Still some write up to do for everyone (tomorrow's job at the sprints), but you should be able to click through already and see the logs. Thanks Microsoft for the 20 concurrent builds on Windows, macOS and Linux :) Top-posted from my Windows phone From: Steve Dower Sent: Wednesday, May 16, 2018 18:10 To: python-committers at python.org Subject: [python-committers] Visual Studio Team Services checks on pullrequests Hi all Just a quick note right now - don't have time for all the details. I'm experimenting with using Visual Studio Team Services to do builds of CPython. Right now, you'll probably see failed builds on all PRs while I get security options figured out. These *will not* block your PR, so feel free to ignore them. Apologies for the noise in the meantime. Cheers, STeve _______________________________________________ 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: From benjamin at python.org Thu May 17 01:46:51 2018 From: benjamin at python.org (Benjamin Peterson) Date: Wed, 16 May 2018 22:46:51 -0700 Subject: [python-committers] Visual Studio Team Services checks on pullrequests In-Reply-To: <40mTb25PHvzFqyH@mail.python.org> References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org> <40mTb25PHvzFqyH@mail.python.org> Message-ID: <1526536011.1063117.1375126352.51A2DC99@webmail.messagingengine.com> On Wed, May 16, 2018, at 15:27, Steve Dower wrote: > Thanks Microsoft for the 20 concurrent builds on Windows, macOS and Linux :) That is quite generous! Will it be ongoing? From brett at python.org Thu May 17 09:35:26 2018 From: brett at python.org (Brett Cannon) Date: Thu, 17 May 2018 09:35:26 -0400 Subject: [python-committers] Visual Studio Team Services checks on pullrequests In-Reply-To: <1526536011.1063117.1375126352.51A2DC99@webmail.messagingengine.com> References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org> <40mTb25PHvzFqyH@mail.python.org> <1526536011.1063117.1375126352.51A2DC99@webmail.messagingengine.com> Message-ID: On Thu, 17 May 2018 at 01:47 Benjamin Peterson wrote: > > > On Wed, May 16, 2018, at 15:27, Steve Dower wrote: > > Thanks Microsoft for the 20 concurrent builds on Windows, macOS and > Linux :) > > That is quite generous! Will it be ongoing? > Yes, this is not just for the sprints. This is a continual contribution so this level of performance will be year-round. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.dower at python.org Thu May 17 10:07:44 2018 From: steve.dower at python.org (Steve Dower) Date: Thu, 17 May 2018 10:07:44 -0400 Subject: [python-committers] Visual Studio Team Services checks on pullrequests In-Reply-To: <40mTb03mwLzFqyW@mail.python.org> References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org> <40mTb03mwLzFqyW@mail.python.org> Message-ID: Okay, now that it's morning and I have coffee, here's a full update on what I've been doing (those at the language summit have heard some of this already). Visual Studio Team Services is Microsoft's integrated code/build/release infrastructure service. The official marketing page is https://www.visualstudio.com/team-services/ but you can think of it as github code+github issues+Travis but engineered for huge teams (i.e. Microsoft keeps all of Windows in git, all the millions of issues they have, and all the builds they do, are in VSTS and it scales to thousands of developers just fine). I've been working with the team to improve their Python support and generally raise awareness of the new service, and one of the things they agreed to is to provide a free set of build machines for CPython. These allow us to run up to 20 simultaneous Windows, macOS and Linux builds with no other limits. My main project at the PyCon US sprints has been setting these builds up. As of about 16 hours ago the PR builds are now hooked up to github (for an example, see https://github.com/python/cpython/pull/6933). They are not required to merge, so don't feel the need to block PRs if everything else passes, but we'd like to fix up the issues they are hitting. As far as I can tell, most of the problems are transient test failures that ought to be fixed anyway. Brief interruption for some links: * https://python.visualstudio.com/cpython/_build/index?_a=queued (queued and recently completed builds) * https://github.com/python/cpython/tree/master/.vsts (build definitions) * https://github.com/python/cpython/pull/6933 (sample PR with build status) Authentication for python.visualstudio.com is currently manually managed, but everything relevant under https://python.visualstudio.com/cpython is visible without authentication (this is a new VSTS feature that we got enabled early). Right now I don't want to add lots of people manually, and we'll be looking at how to make this simpler in the future. There isn't much you can do while logged in anyway :) There are some missing features. I'm still in contact with the team and I'll be passing along requests, so feel free to let me know if you need anything. Currently I'm aware of: * no way to requeue a PR build (whether logged in or not) * no link from a build to the github PR page * templated build steps aren't enabled yet (see linux-deps.yml if you're interested) We don't yet have a specific timeline for making VSTS builds required and reducing Travis/AppVeyor usage. I also haven't set up VSTS for Python 2.7, and honestly I'm fine with keeping the existing systems there. As a slight aside, we're also working with some other projects to provide similar setups (specifically Twisted and some PyPA-associated projects), so if you think you'd benefit from this on one of your other projects let me know and we can see what's available. Also, if you start evaluating/using VSTS for other projects because of this, *please* let me know. New users is what the VSTS team is trying to achieve, so every time I can send back positive reports it helps convince them to keep donating build time. Feel free to email me with any questions or feedback, either on or off-list. Cheers, Steve From antoine at python.org Thu May 17 10:14:55 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 17 May 2018 16:14:55 +0200 Subject: [python-committers] Visual Studio Team Services checks on pullrequests In-Reply-To: References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org> <40mTb03mwLzFqyW@mail.python.org> Message-ID: <5b6fe721-e3c8-831c-e306-d44c382375a2@python.org> Le 17/05/2018 ? 16:07, Steve Dower a ?crit?: > Okay, now that it's morning and I have coffee, here's a full update on > what I've been doing (those at the language summit have heard some of > this already). > > Visual Studio Team Services is Microsoft's integrated code/build/release > infrastructure service. The official marketing page is > https://www.visualstudio.com/team-services/ but you can think of it as > github code+github issues+Travis but engineered for huge teams (i.e. > Microsoft keeps all of Windows in git, all the millions of issues they > have, and all the builds they do, are in VSTS and it scales to thousands > of developers just fine). > > I've been working with the team to improve their Python support and > generally raise awareness of the new service, and one of the things they > agreed to is to provide a free set of build machines for CPython. These > allow us to run up to 20 simultaneous Windows, macOS and Linux builds > with no other limits. That sounds cool. Which builds are you looking to migrate to VSTS? macOS sounds like a no-brainer as the Travis-CI macOS infrastructure is known to be very lacking (though it has been a bit better lately). Windows may be reasonable since AppVeyor doesn't provide any parallelism AFAIK. As for Linux, I think it may be better to keep some of our CI on Travis (if only not to depend entirely on a donated service). Also a concern: currently the Travis-CI and AppVeyor configurations also work, transparently, on user's forks as long as they activated those (free) services on their fork. What about VSTS, though? If CPython were to migrate all of its CI to VSTS, would I still get CI on my CPython fork? Regards Antoine. From steve.dower at python.org Thu May 17 10:46:57 2018 From: steve.dower at python.org (Steve Dower) Date: Thu, 17 May 2018 10:46:57 -0400 Subject: [python-committers] Visual Studio Team Services checks on pullrequests In-Reply-To: <5b6fe721-e3c8-831c-e306-d44c382375a2@python.org> References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org> <40mTb03mwLzFqyW@mail.python.org> <5b6fe721-e3c8-831c-e306-d44c382375a2@python.org> Message-ID: On 17May2018 1014, Antoine Pitrou wrote: > That sounds cool. Which builds are you looking to migrate to VSTS? > macOS sounds like a no-brainer as the Travis-CI macOS infrastructure is > known to be very lacking (though it has been a bit better lately). > Windows may be reasonable since AppVeyor doesn't provide any parallelism > AFAIK. As for Linux, I think it may be better to keep some of our CI on > Travis (if only not to depend entirely on a donated service). That sounds fine. It'll be decided on core-workflow, but I tried to enable everything (except the 2.7 branch :) ) > Also a concern: currently the Travis-CI and AppVeyor configurations also > work, transparently, on user's forks as long as they activated those > (free) services on their fork. What about VSTS, though? If CPython > were to migrate all of its CI to VSTS, would I still get CI on my > CPython fork? I've enabled as much as I have options for (including clicking through the security warnings), so if it's still lacking in certain areas then I'll pass that feedback along. It definitely runs against PRs sent from forks, but I don't think it'll run against pushes to your own fork unless you sign up for your own (free) instance. The YAML files should work fine though, but they won't automatically create themselves. Cheers, Steve From tjreedy at udel.edu Thu May 17 10:59:32 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 17 May 2018 10:59:32 -0400 Subject: [python-committers] Visual Studio Team Services checks on pullrequests In-Reply-To: References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org> <40mTb03mwLzFqyW@mail.python.org> Message-ID: On 5/17/2018 10:07 AM, Steve Dower wrote: > Feel free to email me with any questions or feedback, either on or off-list. When a test fails and verbose test by test output is displayed, it would be really nice if error lines, or at least 'ERROR' were highlighted more somehow. Either in red (hard with plain text, I guess) or ***ERROR***, for instance. In the example, test_asyncio failed (this is a know intermittent problem) and includes lines like test_sock_sendfile_fallback (test.test_asyncio.test_base_events.BaseLoopSockSendfileTests) ... ERROR with no traceback. It is hard to be sure that one has seen all such lines. tjr From storchaka at gmail.com Thu May 17 14:31:37 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Thu, 17 May 2018 21:31:37 +0300 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: References: Message-ID: <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com> 15.05.18 14:51, Ned Deily ????: > This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your > feature fixes, bug fixes, and documentation updates in before > 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days > from now. We will then tag and produce the 3.7.0 release candidate. > Our goal continues been to be to have no changes between the release > candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 > BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are > no critical problems outstanding and that documentation for new > features in 3.7 is complete (including NEWS and What's New items), and > that 3.7 is getting exposure and tested with our various platorms and > third-party distributions and applications. Those of us who are > participating in the development sprints at PyCon US 2018 here in > Cleveland can feel the excitement building as we work through the > remaining issues, including completing the "What's New in 3.7" > document and final feature documentation. (We wish you could all be > here.) The "What's New in 3.7" document is still not complete. Actually it is far completing. In the previous releases somebody made a thoughtful review of the NEWS file and added all significant changes in What's New, and also removed insignificant entries, reorganized entries, fixed errors, improved wording and formatting. Many thanks to Martin Panter, Elvis Pranskevichus, Yury Selivanov, R. David Murray, Nick Coghlan, Antoine Pitrou, Victor Stinner and others for their great work! But seems in 3.7 this documents doesn't have an editor. From nad at python.org Thu May 17 14:39:35 2018 From: nad at python.org (Ned Deily) Date: Thu, 17 May 2018 14:39:35 -0400 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com> References: <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com> Message-ID: <5B1F42D3-5BAD-47C5-8276-0CE4203834AD@python.org> Elvis has been working on the What?s New doc at the sprints this week. He should be checking in his edits soon. Stay tuned! -- Ned Deily nad at python.org -- [] > On May 17, 2018, at 14:31, Serhiy Storchaka wrote: > > 15.05.18 14:51, Ned Deily ????: >> This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your >> feature fixes, bug fixes, and documentation updates in before >> 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days >> from now. We will then tag and produce the 3.7.0 release candidate. >> Our goal continues been to be to have no changes between the release >> candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 >> BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are >> no critical problems outstanding and that documentation for new >> features in 3.7 is complete (including NEWS and What's New items), and >> that 3.7 is getting exposure and tested with our various platorms and >> third-party distributions and applications. Those of us who are >> participating in the development sprints at PyCon US 2018 here in >> Cleveland can feel the excitement building as we work through the >> remaining issues, including completing the "What's New in 3.7" >> document and final feature documentation. (We wish you could all be >> here.) > > The "What's New in 3.7" document is still not complete. Actually it is far completing. In the previous releases somebody made a thoughtful review of the NEWS file and added all significant changes in What's New, and also removed insignificant entries, reorganized entries, fixed errors, improved wording and formatting. Many thanks to Martin Panter, Elvis Pranskevichus, Yury Selivanov, R. David Murray, Nick Coghlan, Antoine Pitrou, Victor Stinner and others for their great work! But seems in 3.7 this documents doesn't have an editor. > From storchaka at gmail.com Thu May 17 15:14:11 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Thu, 17 May 2018 22:14:11 +0300 Subject: [python-committers] [Python-Dev] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <15747132.OTsdByEcpE@hammer.magicstack.net> References: <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com> <15747132.OTsdByEcpE@hammer.magicstack.net> Message-ID: <6b2cbd3c-1db7-5ef4-da18-33d19c765229@gmail.com> 17.05.18 21:43, Elvis Pranskevichus ????: > I'm working on the What's New document. Will start putting PRs in the > next few days. Great! From brett at python.org Thu May 17 14:39:14 2018 From: brett at python.org (Brett Cannon) Date: Thu, 17 May 2018 14:39:14 -0400 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com> References: <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com> Message-ID: On Thu, 17 May 2018 at 14:31 Serhiy Storchaka wrote: > 15.05.18 14:51, Ned Deily ????: > > This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your > > feature fixes, bug fixes, and documentation updates in before > > 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days > > from now. We will then tag and produce the 3.7.0 release candidate. > > Our goal continues been to be to have no changes between the release > > candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 > > BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are > > no critical problems outstanding and that documentation for new > > features in 3.7 is complete (including NEWS and What's New items), and > > that 3.7 is getting exposure and tested with our various platorms and > > third-party distributions and applications. Those of us who are > > participating in the development sprints at PyCon US 2018 here in > > Cleveland can feel the excitement building as we work through the > > remaining issues, including completing the "What's New in 3.7" > > document and final feature documentation. (We wish you could all be > > here.) > > The "What's New in 3.7" document is still not complete. Actually it is > far completing. In the previous releases somebody made a thoughtful > review of the NEWS file and added all significant changes in What's New, > and also removed insignificant entries, reorganized entries, fixed > errors, improved wording and formatting. Many thanks to Martin Panter, > Elvis Pranskevichus, Yury Selivanov, R. David Murray, Nick Coghlan, > Antoine Pitrou, Victor Stinner and others for their great work! But > seems in 3.7 this documents doesn't have an editor. > Maybe we should start thinking about flagging PRs or issues as needing a What's New entry to help track when they need one, or always expect it in a PR and ignore that requirement when a 'skip whats new' label is applied. That would at least make it easier to keep track of what needs to be done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Thu May 17 20:27:32 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 17 May 2018 20:27:32 -0400 Subject: [python-committers] Visual Studio Team Services checks on pullrequests In-Reply-To: References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org> <40mTb03mwLzFqyW@mail.python.org> <5b6fe721-e3c8-831c-e306-d44c382375a2@python.org> Message-ID: <4b20f58b-6a42-8069-2522-6f0e7a8b8649@udel.edu> Can VSTS run GUI tests on any of the systems? Right now, only Appveyor and one or two of the Windows buildbots do so. From njs at pobox.com Thu May 17 20:31:32 2018 From: njs at pobox.com (Nathaniel Smith) Date: Thu, 17 May 2018 17:31:32 -0700 Subject: [python-committers] Visual Studio Team Services checks on pullrequests In-Reply-To: <4b20f58b-6a42-8069-2522-6f0e7a8b8649@udel.edu> References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org> <40mTb03mwLzFqyW@mail.python.org> <5b6fe721-e3c8-831c-e306-d44c382375a2@python.org> <4b20f58b-6a42-8069-2522-6f0e7a8b8649@udel.edu> Message-ID: On Thu, May 17, 2018 at 5:27 PM, Terry Reedy wrote: > Can VSTS run GUI tests on any of the systems? Right now, only Appveyor and > one or two of the Windows buildbots do so. It's certainly possible to use Xvfb to run headless GUI tests on Linux (or other Unixes that use X11). Any CI service should be able to handle this, e.g.: https://docs.travis-ci.com/user/gui-and-headless-browsers/#Using-xvfb-to-Run-Tests-That-Require-a-GUI -n -- Nathaniel J. Smith -- https://vorpus.org From tjreedy at udel.edu Thu May 17 21:09:18 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 17 May 2018 21:09:18 -0400 Subject: [python-committers] Can I just rerun a test on AppVeyor? Message-ID: I can restart a test on just Travis when AppVeyor (and now MSTS) all passed. But for the last few hours, test_async has failed 1/4 to 1/3 of the runs. This means that test_async failed twice, so I suspect that it actually fails about half the time. A connection error seems to be the main culprit. I could not find a rebuild button on the AppVeyor page, even after connecting my github account with AppVeyor. I ended up closing and reopening, but this wastes resources on Travis and now MSTS. On the rerun, it failed the first time and then passed on the rerun From zachary.ware+pydev at gmail.com Thu May 17 22:36:27 2018 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Thu, 17 May 2018 21:36:27 -0500 Subject: [python-committers] Can I just rerun a test on AppVeyor? In-Reply-To: References: Message-ID: On Thu, May 17, 2018 at 8:09 PM, Terry Reedy wrote: > I can restart a test on just Travis when AppVeyor (and now MSTS) all passed. > But for the last few hours, test_async has failed 1/4 to 1/3 of the runs. > This means that test_async failed twice, so I suspect that it actually fails > about half the time. A connection error seems to be the main culprit. > > I could not find a rebuild button on the AppVeyor page, even after > connecting my github account with AppVeyor. I ended up closing and > reopening, but this wastes resources on Travis and now MSTS. > > On the rerun, it failed the first time and then passed on the rerun It is unfortunately non-obvious that you have to choose "python" rather than your own GitHub username after clicking the "login via GitHub" button, but after logging in that way you should have a "Re-build PR" button at the top of the page of any PR build. I'm not certain that permissions were set correctly before, but they definitely should be now. -- Zach From tjreedy at udel.edu Thu May 17 22:44:48 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 17 May 2018 22:44:48 -0400 Subject: [python-committers] Can I just rerun a test on AppVeyor? In-Reply-To: References: Message-ID: <93c6b433-2f89-1970-91e2-a3be5d9a248f@udel.edu> On 5/17/2018 10:36 PM, Zachary Ware wrote: > On Thu, May 17, 2018 at 8:09 PM, Terry Reedy wrote: >> I can restart a test on just Travis when AppVeyor (and now MSTS) all passed. >> But for the last few hours, test_async has failed 1/4 to 1/3 of the runs. >> This means that test_async failed twice, so I suspect that it actually fails >> about half the time. A connection error seems to be the main culprit. >> >> I could not find a rebuild button on the AppVeyor page, even after >> connecting my github account with AppVeyor. I ended up closing and >> reopening, but this wastes resources on Travis and now MSTS. >> >> On the rerun, it failed the first time and then passed on the rerun > > It is unfortunately non-obvious that you have to choose "python" > rather than your own GitHub username after clicking the "login via > GitHub" button, You're right. I choose my name. 0-(. In retrospect, it makes sense since the job is being done on the python account, not mine. > but after logging in that way you should have a > "Re-build PR" button at the top of the page of any PR build. > > I'm not certain that permissions were set correctly before, but they > definitely should be now. Thanks. From greg at krypto.org Fri May 18 00:25:13 2018 From: greg at krypto.org (Gregory P. Smith) Date: Thu, 17 May 2018 21:25:13 -0700 Subject: [python-committers] Bring back Travis & AppVeyor, make VSTS non-blocking Message-ID: VSTS is clearly not yet a stable continuous integration platform. It needs to be made non-blocking, and AppVeyor and Travis need to be brought back! Examples: https://github.com/python/cpython/pull/6938#issuecomment-389908094 Windows broke - https://python.visualstudio.com/cpython/_build?buildId=522 https://github.com/python/cpython/pull/6939 Linux broke - https://python.visualstudio.com/cpython/_build?buildId=523 This was on a documentation-only change. We cannot be changing to new PR-merge-blocking continuous integration services at this point during a release cycle. This is preventing changes from making it in. -gps -------------- next part -------------- An HTML attachment was scrubbed... URL: From storchaka at gmail.com Fri May 18 03:55:14 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Fri, 18 May 2018 10:55:14 +0300 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: References: <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com> Message-ID: <9a0fdca2-b9a7-aa7d-4007-e30e677940be@gmail.com> 17.05.18 21:39, Brett Cannon ????: > Maybe we should start thinking about flagging PRs or issues as needing > a What's New entry to help track when they need one, or always expect > it in a PR and ignore that requirement when a 'skip whats new' label > is applied. That would at least make it easier to keep track of what > needs to be done. The requirement of flagging PRs or issues as needing a What's New entry doesn't differ in principle from the requirement of creating a What's New entry for these changes. The latter is good, and I'm trying always create a What's New entry for significant enhancement or potentially breaking change. And even I sometimes is unsure and don't document some important changes (like in issue30399). Needed a look of yet one pair of eyes. As for requiring a What's New entry by default and introducing a 'skip whats new' label, I suppose this will add much nuisance. Most PRs (except docs and tests changes) need a news entry, but most PRs don't need a What's New entry because their are bug fixes. Therefore a 'skip whats new' label will be required much more times than 'skip news' or 'skip issue' labels. A thing that can help is a tool that makes a structural diff between NEWS files for different versions and between different branches. It will filter out bugfix changes. The simple 'diff' is not well appropriate because entries can be in different order, and news entries now are scattered between several files, and news entries for previous version sometimes should be searched in different files, and sometimes should be searched on a different branch. The text of entries in different versions can also be different because the same issue can change the behavior on the master and backport the part of changes as a bugfix. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Fri May 18 12:41:21 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 18 May 2018 12:41:21 -0400 Subject: [python-committers] Bring back Travis & AppVeyor, make VSTS non-blocking In-Reply-To: References: Message-ID: <93977d72-9972-03d3-d59e-791d63a7320f@udel.edu> On 5/18/2018 12:25 AM, Gregory P. Smith wrote: > VSTS is clearly not yet a stable continuous integration platform.? It > needs to be made non-blocking, and AppVeyor and Travis need to be > brought back! > > Examples: > https://github.com/python/cpython/pull/6938#issuecomment-389908094 > ? ?Windows broke - > https://python.visualstudio.com/cpython/_build?buildId=522 > https://github.com/python/cpython/pull/6939 > ? ?Linux broke - https://python.visualstudio.com/cpython/_build?buildId=523 Travis and AppVeyor are there on both issues, and both can be merged -- manually -- by pressing 'Squach and merge', even though not green. The VSTS results are not blocking -- they are not marked as 'Required'. The problem is that miss-islington was not changed, and sees any VSTS failure as a status check failure and a reason to not do the automerge you requested by approving the change. > This was on a documentation-only change. > > We cannot be changing to new PR-merge-blocking continuous integration > services at this point during a release cycle.? This is preventing > changes from making it in. What *is* blocking merges and making them painful at times are the haphazard failures of test_asyncio on the blocking bots, Travis and AppVeyor, at a rate as high as 1/4 of individual test runs. See https://bugs.python.org/issue33531 On one backport last night, I had to run Travis 4 times, which means I had to periodically monitor the backport instead of approve and forget. And then I had to manually merge. tjr From guido at python.org Fri May 18 18:25:37 2018 From: guido at python.org (Guido van Rossum) Date: Fri, 18 May 2018 15:25:37 -0700 Subject: [python-committers] A different way to focus discussions Message-ID: Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-) I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes. This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion. PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo). Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic. Thoughts? (We can dogfood this proposal too, if there's interest. :-) -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From levkivskyi at gmail.com Fri May 18 18:58:32 2018 From: levkivskyi at gmail.com (Ivan Levkivskyi) Date: Fri, 18 May 2018 18:58:32 -0400 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: I would like to clarify, what would be a typical time-line for a PEP? Will it look like this: 0. Preliminary discussions to determine whether an idea is PEP-worthy (can happen anywhere, python-ideas, SIGs, even offline) 1. A PEP number is requested by a champion and assigned by a PEP editor (in python/peps repo) 2. PEP is drafted and discussed by a narrow circle of interested participants (happens in a separate repo) 3. When PEP is ready and polished make a PR to python/peps repo, and post it to python-dev to get feedback (if any) from a wider audience 4. If reasonable objections appear at this step, go to step 2 5. Repeat steps 2-4 until accepted/rejected/deferred Is this what you propose? Or you want to completely avoid posting to python-dev? -- Ivan On 18 May 2018 at 18:25, Guido van Rossum wrote: > Discussing PEPs on python-dev and python-ideas is clearly not scalable any > more. (Even python-committers probably doesn't scale too well. :-) > > I wonder if it would make sense to require that for each PEP a new GitHub > *repo* be created whose contents would just be a draft PEP and whose issue > tracker and PR manager would be used to debate the PEP and propose specific > changes. > > This way the discussion is still public: when the PEP-specific repo is > created the author(s) can notify python-ideas, and when they are closer to > submitting they can notify python-dev, but the discussion doesn't attract > uninformed outsiders as much as python-{dev,ideas} discussions do, and it's > much easier for outsiders who want to learn more about the proposal to find > all relevant discussion. > > PEP authors may also choose to use a different repo hosting site, e.g. > Bitbucket or GitLab. We can provide a script that allows checking the > formatting of the PEP easily (basically pep2html.py from the peps repo). > > Using a separate repo per PEP has the advantage that people interested in > a topic can subscribe to all traffic in that repo -- if we were to use the > tracker of the peps repo you would have to subscribe to all peps traffic. > > Thoughts? (We can dogfood this proposal too, if there's interest. :-) > > -- > --Guido van Rossum (python.org/~guido) > > _______________________________________________ > 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: From willingc at gmail.com Fri May 18 19:13:13 2018 From: willingc at gmail.com (Carol Willing) Date: Fri, 18 May 2018 16:13:13 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: > On May 18, 2018, at 3:25 PM, Guido van Rossum > wrote: > > Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-) > > I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes. > We have something similar for Project Jupyter. We have a jupyter-incubator org for third party projects that may someday be accepted into the Jupyter core. One repo in particular, https://github.com/jupyter-incubator/proposals , keeps track of all the currently active proposals with links out to their repos, if not hosted within the incubator org. > This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion. > > PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo). > > Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic. This makes sense - one repo per proposed PEP as PRs can be used to help iterate the wording and issues can focus on specific subtopics. Having one repo that acts as a landing page for all of the in-progress PEPs would help folks keep track of where an in-progress PEP is located. > > Thoughts? (We can dogfood this proposal too, if there's interest. :-) > > -- > --Guido van Rossum (python.org/~guido ) > _______________________________________________ > 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: From greg at krypto.org Fri May 18 19:29:01 2018 From: greg at krypto.org (Gregory P. Smith) Date: Fri, 18 May 2018 16:29:01 -0700 Subject: [python-committers] Travis & AppVeyor hidden on Github, scroll the invisible region to see them. In-Reply-To: <93977d72-9972-03d3-d59e-791d63a7320f@udel.edu> References: <93977d72-9972-03d3-d59e-791d63a7320f@udel.edu> Message-ID: On Fri, May 18, 2018 at 9:45 AM Terry Reedy wrote: > On 5/18/2018 12:25 AM, Gregory P. Smith wrote: > > VSTS is clearly not yet a stable continuous integration platform. It > > needs to be made non-blocking, and AppVeyor and Travis need to be > > brought back! > > > > Examples: > > https://github.com/python/cpython/pull/6938#issuecomment-389908094 > > Windows broke - > > https://python.visualstudio.com/cpython/_build?buildId=522 > > https://github.com/python/cpython/pull/6939 > > Linux broke - > https://python.visualstudio.com/cpython/_build?buildId=523 > > Travis and AppVeyor are there on both issues, and both can be merged -- > manually -- by pressing 'Squach and merge', even though not green. The > VSTS results are not blocking -- they are not marked as 'Required'. Sorry! A combination of github UX flaws led me to misunderstand what I was seeing. The things I wanted to see were still run, but they are not displayed, so I assumed they were gone. That plus the no green button made me assume the new things that were displayed containing one red item were all that there was to see and that they were blocking everything. There is a hidden secret scrolling region when "show all checks" is active on github instead of actually showing all. It only shows five (read: not the five I want). The things I wanted to see were at the bottom and thus not displayed as it puts the VSTS builds up top for some unknown to me reason. I am intentionally not merging those PRs yet as I referred to them from several places as examples of this problem. The > problem is that miss-islington was not changed, and sees any VSTS > failure as a status check failure and a reason to not do the automerge > you requested by approving the change. > That at least we can fix until we trust VSTS to be reliable. As is, the more checkers we have to block on, the more likely anything flaky (either infrastructure or tests+code itself) is to block any given change. What do people think about teaching miss-islington how to re-launch specific CI runs a few times to deflake failures? ("1 out of n passes counts as a pass") - That requires compute resources, but when it is what the human is going to need to do anyways... why not reduce the need and just automate it the first couple of times? I don't know how feasible this is for any given CI system we use today on CPython given the various ways in which they operate. -gps > > > This was on a documentation-only change. > > > > We cannot be changing to new PR-merge-blocking continuous integration > > services at this point during a release cycle. This is preventing > > changes from making it in. > > What *is* blocking merges and making them painful at times are the > haphazard failures of test_asyncio on the blocking bots, Travis and > AppVeyor, at a rate as high as 1/4 of individual test runs. See > https://bugs.python.org/issue33531 > On one backport last night, I had to run Travis 4 times, which means I > had to periodically monitor the backport instead of approve and forget. > And then I had to manually merge. > > tjr > > > _______________________________________________ > 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: From guido at python.org Fri May 18 19:41:42 2018 From: guido at python.org (Guido van Rossum) Date: Fri, 18 May 2018 16:41:42 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: On Fri, May 18, 2018 at 3:58 PM, Ivan Levkivskyi wrote: > I would like to clarify, what would be a typical time-line for a PEP? Will > it look like this: > > 0. Preliminary discussions to determine whether an idea is PEP-worthy (can > happen anywhere, python-ideas, SIGs, even offline) > 1. A PEP number is requested by a champion and assigned by a PEP editor > (in python/peps repo) > I expect some proposals to get stuck before they're ever in a state acceptable even as draft PEP, so I'd like to put off requesting a PEP number as long as possible. > 2. PEP is drafted and discussed by a narrow circle of interested > participants (happens in a separate repo) > 3. When PEP is ready and polished make a PR to python/peps repo, and post > it to python-dev to get feedback (if any) from a wider audience > I expect there to be a long trajectory where the PEP does exist in the peps repo but should still be discussed in its own repo. Mentions on python-dev should be limited to the occasional link to the PEP's own repo, with strongly worded requests to go to that repo to provide feedback. > 4. If reasonable objections appear at this step, go to step 2 > The process should be clear that objections posted to python-dev will be ignored -- only objections posted to the PEP's own repo's issue tracker will be considered. > 5. Repeat steps 2-4 until accepted/rejected/deferred > > Is this what you propose? Or you want to completely avoid posting to > python-dev? > I want to completely avoid discussion on python-dev. This probably means we should never post the full text of the PEP there. (We may have to amend PEP 1 to support this.) There are probably some other parts needed too, e.g. guidelines as to when a PEP is considered ripe for copying to the peps repo (and scripts/bots to make repeated copies easy -- e.g. there could be a bot that copies a PEP from that PEP's own repo to the peps repo each time a commit is made to the master branch in its own repo). There could also be guidelines to ensure a PEP is in a fairly non-controversial state (probably using the IETF's motto "rough consensus and working code") before being considered for approval. There's definitely some time when a PEP has an assigned number but is still controversial -- during that state debate on python-dev should be strictly redirected to the PEP's own repo. For some PEPs it may make sense to assign a senior reviewer who decides what's considered non-controversial. We can borrow more from the IETF process for RFCs: https://www.rfc-editor.org/pubprocess/ --Guido PS. Carol: Jupyter's process looks great! I just don't have the guts to propose any serious changes to the physical logistics of publishing PEPs, since changes to the structure of the peps repo are so hard. We still haven't converted all PEPs to .rst format, despite efforts by Mariatta and others, and attempts to move all PEPs to a subdirectory have also failed, due to perpetual lack of resources to complete the task (and e.g. the need to update scripts on python.org whenever the peps repo structure changes). > > -- > Ivan > > > > On 18 May 2018 at 18:25, Guido van Rossum wrote: > >> Discussing PEPs on python-dev and python-ideas is clearly not scalable >> any more. (Even python-committers probably doesn't scale too well. :-) >> >> I wonder if it would make sense to require that for each PEP a new GitHub >> *repo* be created whose contents would just be a draft PEP and whose issue >> tracker and PR manager would be used to debate the PEP and propose specific >> changes. >> >> This way the discussion is still public: when the PEP-specific repo is >> created the author(s) can notify python-ideas, and when they are closer to >> submitting they can notify python-dev, but the discussion doesn't attract >> uninformed outsiders as much as python-{dev,ideas} discussions do, and it's >> much easier for outsiders who want to learn more about the proposal to find >> all relevant discussion. >> >> PEP authors may also choose to use a different repo hosting site, e.g. >> Bitbucket or GitLab. We can provide a script that allows checking the >> formatting of the PEP easily (basically pep2html.py from the peps repo). >> >> Using a separate repo per PEP has the advantage that people interested in >> a topic can subscribe to all traffic in that repo -- if we were to use the >> tracker of the peps repo you would have to subscribe to all peps traffic. >> >> Thoughts? (We can dogfood this proposal too, if there's interest. :-) >> >> -- >> --Guido van Rossum (python.org/~guido) >> >> _______________________________________________ >> 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/ >> >> > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at krypto.org Fri May 18 19:46:00 2018 From: greg at krypto.org (Gregory P. Smith) Date: Fri, 18 May 2018 16:46:00 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: On Fri, May 18, 2018 at 3:28 PM Guido van Rossum wrote: > Discussing PEPs on python-dev and python-ideas is clearly not scalable any > more. (Even python-committers probably doesn't scale too well. :-) > > I wonder if it would make sense to require that for each PEP a new GitHub > *repo* be created whose contents would just be a draft PEP and whose issue > tracker and PR manager would be used to debate the PEP and propose specific > changes. > > This way the discussion is still public: when the PEP-specific repo is > created the author(s) can notify python-ideas, and when they are closer to > submitting they can notify python-dev, but the discussion doesn't attract > uninformed outsiders as much as python-{dev,ideas} discussions do, and it's > much easier for outsiders who want to learn more about the proposal to find > all relevant discussion. > overall I think this idea has merit. flaws? People who haven't yet given attention to the PEP over in its own world are likely to spawn the same threads on -ideas or -dev when the PEP is introduced there. So long as something is public, there will always be outsiders. It also seems like using a forum such as a repository full of PRs threads can lose the discussion history as PRs are not a mailing list archive and can disappear at the whim of the corporation hosting them. But do we care about that? In theory all arguments and alternatives for/against are _supposed_ to be captured into the PEP doc itself before it is accepted. I do like the ability to have a technical code discussion in markdown as PRs allow vs email. But if there are 100 people chiming in, I doubt this would make anything any easier to follow. PEP authors may also choose to use a different repo hosting site, e.g. > Bitbucket or GitLab. We can provide a script that allows checking the > formatting of the PEP easily (basically pep2html.py from the peps repo). > > Using a separate repo per PEP has the advantage that people interested in > a topic can subscribe to all traffic in that repo -- if we were to use the > tracker of the peps repo you would have to subscribe to all peps traffic. > It sounds like your primary goals here are (a) to avoid PEP discussions on the -dev and -ideas mailing lists and (b) to have a central place for all discussions spawned from a specific PEP instead of trying to piece together 18 centithreads with varying subjects from python-* list archives. I think (a) would happen at the start, and (b) would be true in this scenario so it is probably worth a try. I do expect (a) to overflow to the mailing list anyways at times. But this would give us the opportunity to redirect that away from the list. It should still be better than the common mailing list free for all we have today. It seems a bit more like a "working group" system. (which is what Carol's description of Jupyter incubator reminds me of) *repos* where PEP discussions take place could optionally be CPython forks with an example implementation to eventually be used to construct the ultimate PRs adding it if the PEP is accepted. > Thoughts? (We can dogfood this proposal too, if there's interest. :-) > I'm all for picking a victom^Wvolunteer PEP to try dogfood it on. -gps -------------- next part -------------- An HTML attachment was scrubbed... URL: From levkivskyi at gmail.com Fri May 18 19:51:25 2018 From: levkivskyi at gmail.com (Ivan Levkivskyi) Date: Fri, 18 May 2018 19:51:25 -0400 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: On 18 May 2018 at 19:46, Gregory P. Smith wrote: > > I'm all for picking a victom^Wvolunteer PEP to try dogfood it on. > > Can few related PEPs share the same repository? For example, I want to start writing three PEPs about extensions to PEP 484 type system: literal types, final/const qualifier, and integer generics (simple dependent types). They all are tightly connected (but I don't want a single mega-PEP), can I put these three in the same repo? -- Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Fri May 18 20:02:28 2018 From: guido at python.org (Guido van Rossum) Date: Fri, 18 May 2018 17:02:28 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: Yes, you can do that. On Fri, May 18, 2018, 16:51 Ivan Levkivskyi wrote: > On 18 May 2018 at 19:46, Gregory P. Smith wrote: > >> >> I'm all for picking a victom^Wvolunteer PEP to try dogfood it on. >> >> > Can few related PEPs share the same repository? For example, I want to > start writing three PEPs about extensions to PEP 484 type system: literal > types, final/const qualifier, and integer generics (simple dependent types). > They all are tightly connected (but I don't want a single mega-PEP), can I > put these three in the same repo? > > -- > Ivan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Fri May 18 20:10:52 2018 From: vstinner at redhat.com (Victor Stinner) Date: Sat, 19 May 2018 02:10:52 +0200 Subject: [python-committers] Comments on moving issues to GitHub Message-ID: Hi, I failed to get the microphone after Mariatta's secret talk about moving Python issues from bugs.python.org (Roundup) to GitHub. I just wanted to add that it's common (at least once per month) that someone comes to #python-dev to report that they cannot connect to bugs.python.org (the authentication is broken). Usually, I tried to point them to the meta-bug tracker, but I hate doing that... The concept of a meta-bug tracker blows my mind :-) Right now, I tied to add a comment on an issue and I got the error: """ Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /issue32534. Reason: Error reading from remote server ________________________________ Apache/2.2.16 (Debian) Server at bugs.python.org Port 443 """ Sometimes, I get a SSL error. I reported the issue 7 months ago, and sometimes I still get the error: https://github.com/python/psf-infra-meta/issues/4 It's a random error, but using a loop, it's easy to reproduce it. I don't have a strong opinion about moving issues to GitHub. I just wanted to point out that if we keep bugs.python.org, we need more volunteers to maintain it. I would prefer to not have to redirect new comers, who want to report a simple bug, to a "meta bug tracker"... I don't plan to report the proxy error, since my previous bug report (SSL error) is still not fixed and it's the first time that I got this error. Victor From njs at pobox.com Fri May 18 21:29:24 2018 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 18 May 2018 18:29:24 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: On Fri, May 18, 2018 at 3:25 PM, Guido van Rossum wrote: > Discussing PEPs on python-dev and python-ideas is clearly not scalable any > more. (Even python-committers probably doesn't scale too well. :-) PEP 572 seems like something of a perfect storm... it's simultaneously a bikeshed and a nuclear power plant [1], and also the rare proposal that you like but that significant numbers of core devs find deeply objectionable; any one of these would tend to produce a lot of email, and then the combination is something else again. Is this proposal mostly responding to that, or something that you've been thinking for a while? [1] For those unfamiliar with this example: https://en.wikipedia.org/wiki/Law_of_triviality#Examples > I wonder if it would make sense to require that for each PEP a new GitHub > *repo* be created whose contents would just be a draft PEP and whose issue > tracker and PR manager would be used to debate the PEP and propose specific > changes. To some extent this has been happening informally for a while. Just off the top of my head: PEP 465: https://github.com/numpy/numpy/pull/4351 PEP 543: https://github.com/python-hyper/pep543/issues/2#issuecomment-309199376 PEP 513: https://github.com/pypa/manylinux#the-pep-itself A repo full of packaging PEPs: https://github.com/pypa/interoperability-peps For a lot of us these days, putting a document in a repo is just the default way to work on it (and get feedback, etc.). Managing the relationship between these repos and the main peps repo is currently pretty awkward. They tend to get out of sync in both directions ? people make edits directly to the PEP repo ? plus in general some pieces of information are in one place and some in another, there's no link between them, the original repo can get misplaced over time... > This way the discussion is still public: when the PEP-specific repo is > created the author(s) can notify python-ideas, and when they are closer to > submitting they can notify python-dev, but the discussion doesn't attract > uninformed outsiders as much as python-{dev,ideas} discussions do, and it's > much easier for outsiders who want to learn more about the proposal to find > all relevant discussion. > > PEP authors may also choose to use a different repo hosting site, e.g. > Bitbucket or GitLab. We can provide a script that allows checking the > formatting of the PEP easily (basically pep2html.py from the peps repo). I'd be somewhat tempted to require people to use Github and to move the repo into the python/ organization when it gets a number, so that there's one canonical place to look for the history and we have some control over its lifecycle. More radical idea: what if the PEPs index just linked to the Github rendering of each file? That's always going to be up to date, it comes with a link to the issue tracker at the top, it has a nice "Edit" button if someone wants to submit small fixes as a PR... > Using a separate repo per PEP has the advantage that people interested in a > topic can subscribe to all traffic in that repo -- if we were to use the > tracker of the peps repo you would have to subscribe to all peps traffic. > > Thoughts? (We can dogfood this proposal too, if there's interest. :-) Rust's RFC process is a bit different, but may be of interest: https://github.com/rust-lang/rfcs One thing people might worry about is missing out on discussion they're interested in ? there wouldn't be one central place to subscribe to see discussions. Rust's concept of a "final comment period" is a nice way to manage this. -n -- Nathaniel J. Smith -- https://vorpus.org From njs at pobox.com Fri May 18 21:33:00 2018 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 18 May 2018 18:33:00 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: On Fri, May 18, 2018 at 4:51 PM, Ivan Levkivskyi wrote: > On 18 May 2018 at 19:46, Gregory P. Smith wrote: >> >> >> I'm all for picking a victom^Wvolunteer PEP to try dogfood it on. >> > > Can few related PEPs share the same repository? For example, I want to start > writing three PEPs about extensions to PEP 484 type system: literal types, > final/const qualifier, and integer generics (simple dependent types). > They all are tightly connected (but I don't want a single mega-PEP), can I > put these three in the same repo? Another common pattern we see with trickier PEPs is the creation of multiple competing proposals. This strikes me as healthy and something we want to encourage. Maybe these should also go in the same repo by default? This is also a case where assigning PEP numbers earlier rather than later seems useful. Unambiguously referring to PEP 521, PEP 550, PEP 567, and PEP 568 would be difficult without the numbers :-). -n -- Nathaniel J. Smith -- https://vorpus.org From njs at pobox.com Fri May 18 22:39:59 2018 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 18 May 2018 19:39:59 -0700 Subject: [python-committers] Travis & AppVeyor hidden on Github, scroll the invisible region to see them. In-Reply-To: References: <93977d72-9972-03d3-d59e-791d63a7320f@udel.edu> Message-ID: On Fri, May 18, 2018 at 4:29 PM, Gregory P. Smith wrote: > What do people think about teaching miss-islington how to re-launch specific > CI runs a few times to deflake failures? ("1 out of n passes counts as a > pass") - That requires compute resources, but when it is what the human is > going to need to do anyways... why not reduce the need and just automate it > the first couple of times? I don't know how feasible this is for any given > CI system we use today on CPython given the various ways in which they > operate. This can also be done with a loop inside individual tests, which would avoid complications with CI APIs and make sure that if any new flaky tests show up then we'll notice it. -n -- Nathaniel J. Smith -- https://vorpus.org From antoine at python.org Sat May 19 01:45:56 2018 From: antoine at python.org (Antoine Pitrou) Date: Sat, 19 May 2018 07:45:56 +0200 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: Hi, Note that some PEPs are, still, mostly uncontroversial (PEP 574 is an example). I agree with Nathaniel : PEP 572 is the poster child for lengthy, heated discussions. I'm still surprised you thought it was a good idea to discuss this. Perhaps it we tried to discourage syntax change and/or builtin change PEPs a little more we'd have less heated PEPs :-) It would be *very* interesting if someone was willing to do some stats on PEPs over time: e.g. number of PEPs discussed every year, discussion length, number of discusssion participants. I actually expect overall PEP activity to have gone down since the 2000s. Le 19/05/2018 ? 01:41, Guido van Rossum a ?crit?: > I want to completely avoid discussion on python-dev. This probably means > we should never post the full text of the PEP there. (We may have to > amend PEP 1 to support this.) Are you saying PEPs wouldn't even be *validated* by python-dev? If so, it's not a mere change to focus discussions, it's also a change in governance. And while we may decide to change this piece of the governance model, the replacement process should IMO be something a little less vague than ? discussion happens on Github with whoever happens to be interested or available ?. Sorry if this is misrepresenting your position. Regards Antoine. > There are probably some other parts needed too, e.g. guidelines as to > when a PEP is considered ripe for copying to the peps repo (and > scripts/bots to make repeated copies easy -- e.g. there could be a bot > that copies a PEP from that PEP's own repo to the peps repo each time a > commit is made to the master branch in its own repo). There could also > be guidelines to ensure a PEP is in a fairly non-controversial state > (probably using the IETF's motto "rough consensus and working code") > before being considered for approval. There's definitely some time when > a PEP has an assigned number but is still controversial -- during that > state debate on python-dev should be strictly redirected to the PEP's > own repo. > > For some PEPs it may make sense to assign a senior reviewer who decides > what's considered non-controversial. > > We can borrow more from the IETF process for RFCs: > https://www.rfc-editor.org/pubprocess/ > > --Guido > > PS. Carol: Jupyter's process looks great! I just don't have the guts to > propose any serious changes to the physical logistics of publishing > PEPs, since changes to the structure of the peps repo are so hard. We > still haven't converted all PEPs to .rst format, despite efforts by > Mariatta and others, and attempts to move all PEPs to a subdirectory > have also failed, due to perpetual lack of resources to complete the > task (and e.g. the need to update scripts on python.org > whenever the peps repo structure changes). From storchaka at gmail.com Sat May 19 02:52:14 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Sat, 19 May 2018 09:52:14 +0300 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: <46caeafe-b821-667c-76b4-450b681f69a8@gmail.com> 19.05.18 01:25, Guido van Rossum ????: > I wonder if it would make sense to require that for each PEP a new > GitHub *repo* be created whose contents would just be a draft PEP and > whose issue tracker and PR manager would be used to debate the PEP and > propose specific changes. > > This way the discussion is still public: when the PEP-specific repo is > created the author(s) can notify python-ideas, and when they are > closer to submitting they can notify python-dev, but the discussion > doesn't attract uninformed outsiders as much as python-{dev,ideas} > discussions do, and it's much easier for outsiders who want to learn > more about the proposal to find all relevant discussion. > > PEP authors may also choose to use a different repo hosting site, e.g. > Bitbucket or GitLab. We can provide a script that allows checking the > formatting of the PEP easily (basically pep2html.py from the peps repo). What will happen with these repos after accepting or rejecting corresponding PEPs? From p.f.moore at gmail.com Sat May 19 06:36:25 2018 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 19 May 2018 11:36:25 +0100 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: On 18 May 2018 at 23:25, Guido van Rossum wrote: > Discussing PEPs on python-dev and python-ideas is clearly not scalable any > more. (Even python-committers probably doesn't scale too well. :-) It's not scalable, certainly. But it's still (IMO) fine for all but the larger PEPs - the trick is spotting which PEPs are "too big" :-) I'm not sure that the issue with python-ideas is that bad. That list is *designed* for incomplete and unformed proposals, and so long threads are common (and accepted) on there. People on python-ideas are used to skimming or ignoring/blocking threads they aren't interested in. So by the time things are ready to go to python-dev (or wherever) there's a good sense of whether the PEP is likely to be controversial. I'd suggest that this is the point when the decision to go to python-dev or github could be made. > I wonder if it would make sense to require that for each PEP a new GitHub > *repo* be created whose contents would just be a draft PEP and whose issue > tracker and PR manager would be used to debate the PEP and propose specific > changes. > > This way the discussion is still public: when the PEP-specific repo is > created the author(s) can notify python-ideas, and when they are closer to > submitting they can notify python-dev, but the discussion doesn't attract > uninformed outsiders as much as python-{dev,ideas} discussions do, and it's > much easier for outsiders who want to learn more about the proposal to find > all relevant discussion. > > PEP authors may also choose to use a different repo hosting site, e.g. > Bitbucket or GitLab. We can provide a script that allows checking the > formatting of the PEP easily (basically pep2html.py from the peps repo). I would prefer that PEP repos remain on github, and that once the PEP is finalised (accepted, rejected, whatever) moved under the CPython organisation (the whole repo, issue tracker, history, everything) so that the history of discussion isn't lost. Current PEP discussions are retained on the list archives, and I think the discussion history is valuable (even if a lot of it ends up being noise at the moment). I'd rather not have to maintain extra accounts for bitbucket or gitlab, and learn how notifications and tracking work on those platforms. A common interface is important. Adding barriers to contribution does filter out casual commenters, but I'm sure we don't want to be seen to be deliberately making it *hard* for outsiders to get involved. > Using a separate repo per PEP has the advantage that people interested in a > topic can subscribe to all traffic in that repo -- if we were to use the > tracker of the peps repo you would have to subscribe to all peps traffic. > > Thoughts? (We can dogfood this proposal too, if there's interest. :-) (Later) > I want to completely avoid discussion on python-dev. This probably means we should never post the full text of the PEP there. (We may have to amend PEP 1 to support this.) Avoiding *discussion* is probably OK. But regular summaries of progress would, I think, be critical. Otherwise python-dev is essentially cut out of the loop, and this becomes more of a change in governance, as Antoine mentioned. I'm not quite sure what your intention was, but I'd like to see a series of announcements on python-dev for a PEP which is being discussed offline: 1. An initial announcement of the creation of the PEP repo, giving a summary of the PEP (the abstract from the proposal), and a pointer to where interested parties should go to participate in discussions. 2. Progress announcements, maybe once a month, repeating the summary and adding a "what has changed" summary. 3. Preliminary announcement of the decision on the PEP (a "release candidate" if you like) stating that the decision has been made, what that decision is, and that it will be officially announced in (say) a week. 4. Final announcement, giving the summary, the decision, and pointers to the final PEP text and the discussion (now hosted permanently under the cpython org on github). The point of the "release candidate" stage is the same as the RC for a release - last chance to raise showstopper problems, plus announcing the start of the "release" work (moving the repo, specifically). I'm not that wedded to the RC announcement, but it will avoid the final decision coming as a complete surprise to python-dev. As a data point, I currently have no idea whether the discussions on the binding expression PEP are still just rumbling on, or whether a decision is imminent. Of course, if the progress announcements are sufficiently good, the RC may not be necessary (it would effectively just be the last in a series of summaries). Paul From steve at pearwood.info Sat May 19 10:37:14 2018 From: steve at pearwood.info (Steven D'Aprano) Date: Sun, 20 May 2018 00:37:14 +1000 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: <20180519143714.GY12683@ando.pearwood.info> On Fri, May 18, 2018 at 03:25:37PM -0700, Guido van Rossum wrote: > Discussing PEPs on python-dev and python-ideas is clearly not scalable any > more. (Even python-committers probably doesn't scale too well. :-) > > I wonder if it would make sense to require that for each PEP a new GitHub > *repo* be created whose contents would just be a draft PEP and whose issue > tracker and PR manager would be used to debate the PEP and propose specific > changes. Do we have a reason to think that moving to Github will help discussions scale better? At the moment, a controversial PEP generates a flood of email on Python-Ideas and a flood of email on Python-Dev. If all we do is add a third flood of posts on Github, that's not much of a win :-) Aside from the nuisance value of having to sign up to yet another forum (Github as well as a mailing list), which isn't that big a nuisance given that these days most people have a Github account, I'm not too clear on the benefit of this. > This way the discussion is still public: when the PEP-specific repo is > created the author(s) can notify python-ideas, and when they are closer to > submitting they can notify python-dev, but the discussion doesn't attract > uninformed outsiders as much as python-{dev,ideas} discussions do, and it's > much easier for outsiders who want to learn more about the proposal to find > all relevant discussion. Isn't that a bit of a contradiction? - moving to GitHub doesn't attract outsiders - while making it easier for outsiders -- Steve From antoine at python.org Sun May 20 04:56:21 2018 From: antoine at python.org (Antoine Pitrou) Date: Sun, 20 May 2018 10:56:21 +0200 Subject: [python-committers] Comments on moving issues to GitHub In-Reply-To: References: Message-ID: <005b303f-2055-1057-6434-65dda83fc85a@python.org> Le 19/05/2018 ? 02:10, Victor Stinner a ?crit?: > Hi, > > I failed to get the microphone after Mariatta's secret talk about > moving Python issues from bugs.python.org (Roundup) to GitHub. A "secret talk"? What is that? > I don't have a strong opinion about moving issues to GitHub. If that's on the table, it seems to me that categorization, sorting and filtering on GitHub issues is rather poor, while the basic UI experience (editing messages, etc.) is better. Also, I think customization (e.g. of the default view) is basically inexistent. Regards Antoine. From stefan at bytereef.org Sun May 20 07:45:45 2018 From: stefan at bytereef.org (Stefan Krah) Date: Sun, 20 May 2018 13:45:45 +0200 Subject: [python-committers] Comments on moving issues to GitHub In-Reply-To: <005b303f-2055-1057-6434-65dda83fc85a@python.org> References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> Message-ID: <20180520114545.GA2717@bytereef.org> On Sun, May 20, 2018 at 10:56:21AM +0200, Antoine Pitrou wrote: > If that's on the table, it seems to me that categorization, sorting and > filtering on GitHub issues is rather poor, while the basic UI experience > (editing messages, etc.) is better. Also, I think customization (e.g. > of the default view) is basically inexistent. Also search via Google "site:bugs.python.org " usually gives quite nice results, while the same for GitHub issues usually does not work at all (far too many unrelated results). Then there's the original promise of the GitHub migration that in the case of GH bankruptcy or a sudden lockdown the tracker would still be available. Stefan Krah From njs at pobox.com Sun May 20 13:19:25 2018 From: njs at pobox.com (Nathaniel Smith) Date: Sun, 20 May 2018 10:19:25 -0700 Subject: [python-committers] Comments on moving issues to GitHub In-Reply-To: <005b303f-2055-1057-6434-65dda83fc85a@python.org> References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> Message-ID: On Sun, May 20, 2018, 03:18 Antoine Pitrou wrote: > > Le 19/05/2018 ? 02:10, Victor Stinner a ?crit : > > Hi, > > > > I failed to get the microphone after Mariatta's secret talk about > > moving Python issues from bugs.python.org (Roundup) to GitHub. > > A "secret talk"? What is that? > She gave a talk at the language summit to discuss what people thought of the idea, and she had some fun making the topic a surprise so she could see people's reactions. I don't think there's any secret beyond that. IIRC, the general reaction was that it was definitely worth exploring, but that it would be a lot of work and require solutions to a lot of problems to make sure people's workflows weren't too impacted, so we'd need a much more detailed proposal before any decision could be made. -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Sun May 20 13:42:28 2018 From: barry at python.org (Barry Warsaw) Date: Sun, 20 May 2018 10:42:28 -0700 Subject: [python-committers] Comments on moving issues to GitHub In-Reply-To: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> Message-ID: <58D4E1B2-C0BC-4315-B5DC-307C9BB75214@python.org> On May 20, 2018, at 10:19, Nathaniel Smith wrote: > > IIRC, the general reaction was that it was definitely worth exploring, but that it would be a lot of work and require solutions to a lot of problems to make sure people's workflows weren't too impacted, so we'd need a much more detailed proposal before any decision could be made. Note too that Bryan Clark from GitHub, who I believe is a product manager there, was at the packaging mini-summit. If/when we have a specific set of asks for the migration, we can reach out to him and see how they can help. For example, I specifically asked about my favorite GitLab feature ?commit when CI passes? and it sounded like they were working on that. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From brett at python.org Sun May 20 15:03:59 2018 From: brett at python.org (Brett Cannon) Date: Sun, 20 May 2018 12:03:59 -0700 Subject: [python-committers] Comments on moving issues to GitHub In-Reply-To: <58D4E1B2-C0BC-4315-B5DC-307C9BB75214@python.org> References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <58D4E1B2-C0BC-4315-B5DC-307C9BB75214@python.org> Message-ID: On Sun, 20 May 2018 at 10:43 Barry Warsaw wrote: > On May 20, 2018, at 10:19, Nathaniel Smith wrote: > > > > IIRC, the general reaction was that it was definitely worth exploring, > but that it would be a lot of work and require solutions to a lot of > problems to make sure people's workflows weren't too impacted, so we'd need > a much more detailed proposal before any decision could be made. > > Note too that Bryan Clark from GitHub, who I believe is a product manager > there, was at the packaging mini-summit. If/when we have a specific set of > asks for the migration, we can reach out to him and see how they can help. > For example, I specifically asked about my favorite GitLab feature ?commit > when CI passes? and it sounded like they were working on that. > There was also general consensus that the state of maintenance for bpo is subpar due to lack of staffing and that more people will need to come forward to help maintain it if we decide to not transition to another issue tracker like GitHub or GitLab. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Sun May 20 18:34:29 2018 From: nad at python.org (Ned Deily) Date: Sun, 20 May 2018 18:34:29 -0400 Subject: [python-committers] 3.7.0rc1 deadline extended two days to 2018-05-23 AOE [Re: FINAL WEEK FOR 3.7.0 CHANGES!] In-Reply-To: References: Message-ID: <916214BF-DA73-4380-9C3D-2479CCE3A537@python.org> We are going to extend for 48 hours the deadline for 3.7.0rc1, that is, until 2018-05-23 23:59 AOE. While we have made tremendous progress towards the release candidate over the past week especially with the huge efforts at the PyCon US Sprints, we still have some important issues to resolve. A stumbling block has been the increased instability in the test suite, primarily in test_asyncio, which has caused delays in merging PRs due to intermittent failures in CI test runs and which has caused widespread buildbot failures. Another factor is that this weekend and Monday are public holidays in many countries, something I did not take into account when drawing up the schedule. (Note that next weekend is a major public holiday in the USA.) So let's plan on using the extra two days to work through the remaining release blockers. Thanks again! --Ned On May 15, 2018, at 07:51, Ned Deily wrote: > This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your > feature fixes, bug fixes, and documentation updates in before > 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days > from now. We will then tag and produce the 3.7.0 release candidate. > Our goal continues been to be to have no changes between the release > candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 > BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are > no critical problems outstanding and that documentation for new > features in 3.7 is complete (including NEWS and What's New items), and > that 3.7 is getting exposure and tested with our various platorms and > third-party distributions and applications. Those of us who are > participating in the development sprints at PyCon US 2018 here in > Cleveland can feel the excitement building as we work through the > remaining issues, including completing the "What's New in 3.7" > document and final feature documentation. (We wish you could all be > here.) > > As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You > should now be treating the 3.7 branch as if it were already released > and in maintenance mode. That means you should only push the kinds of > changes that are appropriate for a maintenance release: > non-ABI-changing bug and feature fixes and documentation updates. If > you find a problem that requires an ABI-altering or other significant > user-facing change (for example, something likely to introduce an > incompatibility with existing users' code or require rebuilding of > user extension modules), please make sure to set the b.p.o issue to > "release blocker" priority and describe there why you feel the change > is necessary. If you are reviewing PRs for 3.7 (and please do!), be on > the lookout for and flag potential incompatibilities (we've all made > them). > > Thanks again for all of your hard work towards making 3.7.0 yet > another great release - coming to a website near you on 06-15! > > Release Managerly Yours, > --Ned > > https://www.python.org/dev/peps/pep-0537/ -- Ned Deily nad at python.org -- [] From ncoghlan at gmail.com Mon May 21 06:24:43 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 21 May 2018 20:24:43 +1000 Subject: [python-committers] Comments on moving issues to GitHub In-Reply-To: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <58D4E1B2-C0BC-4315-B5DC-307C9BB75214@python.org> Message-ID: On 21 May 2018 at 05:03, Brett Cannon wrote: > > > On Sun, 20 May 2018 at 10:43 Barry Warsaw wrote: > >> On May 20, 2018, at 10:19, Nathaniel Smith wrote: >> > >> > IIRC, the general reaction was that it was definitely worth exploring, >> but that it would be a lot of work and require solutions to a lot of >> problems to make sure people's workflows weren't too impacted, so we'd need >> a much more detailed proposal before any decision could be made. >> >> Note too that Bryan Clark from GitHub, who I believe is a product manager >> there, was at the packaging mini-summit. If/when we have a specific set of >> asks for the migration, we can reach out to him and see how they can help. >> For example, I specifically asked about my favorite GitLab feature ?commit >> when CI passes? and it sounded like they were working on that. >> > > There was also general consensus that the state of maintenance for bpo is > subpar due to lack of staffing and that more people will need to come > forward to help maintain it if we decide to not transition to another issue > tracker like GitHub or GitLab. > Right, one of the outcomes of the discussion at the Summit was that any proposal to migrate to a different issue tracker would need to present a clear statement of the *problems intended to be solved*, such that the folks that would prefer to see us stay on our own issue tracker could present a competing proposal to solve those problems without a wholesale migration to another system. Some examples of problems that would benefit from attention: - fixing the SSL/TLS connectivity issues - making the issue tracker usable on mobile devices - ability to edit the description for issues that evolve over time, not just the title - improved editing support for comments (both in initial formatting, and in being able to correct errors) - REST API access to tracker data - simplifying account creation (especially for folks that already have GitHub accounts) - rationalising the metadata fields by asking which ones actually see significant use Some examples of problems that in-place enhancement of the tracker would inherently avoid, but a migration proposal would need to address: - preservation of existing incoming links to issues - figuring out which issues to migrate automatically (all of them? None of them? Open issues only?) - figuring out a new way to track PSF CLA signatures - figuring out a replacement for the Experts Index integration into the Roundup nosy list - figuring out replacements for the custom metadata fields that we actually use regularly - meeting our original GitHub migration commitment to continue offering a way of engaging with the core development process without requiring accounts with any entity other than the PSF It's far from being a foregone conclusion that migrating to a new issue tracker will be the preferred answer, but there are also genuine problems with the status quo that need to be addressed somehow. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Mon May 21 14:26:47 2018 From: barry at python.org (Barry Warsaw) Date: Mon, 21 May 2018 11:26:47 -0700 Subject: [python-committers] Comments on moving issues to GitHub In-Reply-To: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> <58D4E1B2-C0BC-4315-B5DC-307C9BB75214@python.org> Message-ID: <563A3482-057F-48EF-9A11-265D4265D5B6@python.org> On May 21, 2018, at 03:24, Nick Coghlan wrote: > Right, one of the outcomes of the discussion at the Summit was that any proposal to migrate to a different issue tracker would need to present a clear statement of the *problems intended to be solved*, such that the folks that would prefer to see us stay on our own issue tracker could present a competing proposal to solve those problems without a wholesale migration to another system. I?d like to see multiple PEPs for this migration. The first would clearly outline discussion points that apply regardless of where we migrate to, or whether we migrate at all. This would include lists of common use cases, the problems with the current system, the features we like (and regularly use!) in the current system, and a list of key points that can be compared against any proposed solution. E.g. for this latter, let?s say one of the points is ?ability to easily ignore all discussions on tickets you don?t care about?. You could imagine a row in a table that shows how any of the proposed solutions compare to what we have today. You could color code this on a gradient, say from dark green (?it will be much better on system X?) to dark red (?it?ll be much more difficult on system Y?). That would be one PEP, and it would be the baseline for making a decision. Additional PEPs would make specific proposals, e.g. move to GH, stay on bpo as is, significantly invest in bpo, etc. They?d reference the baseline PEP and include that table with the color coded rows. Then perhaps after the decision is made, there would maybe be an implementation PEP describing the steps it will take to migrate, and the ETA. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From larry at hastings.org Mon May 21 14:31:48 2018 From: larry at hastings.org (Larry Hastings) Date: Mon, 21 May 2018 11:31:48 -0700 Subject: [python-committers] Comments on moving issues to GitHub In-Reply-To: References: <005b303f-2055-1057-6434-65dda83fc85a@python.org> Message-ID: <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org> On 05/20/2018 10:19 AM, Nathaniel Smith wrote: > On Sun, May 20, 2018, 03:18 Antoine Pitrou > wrote: > > > Le 19/05/2018 ? 02:10, Victor Stinner a ?crit?: > > Hi, > > > > I failed to get the microphone after Mariatta's secret talk about > > moving Python issues from bugs.python.org > (Roundup) to GitHub. > > A "secret talk"? What is that? > > > She gave a talk at the language summit to discuss what people thought > of the idea, and she had some fun making the topic a surprise so she > could see people's reactions. I don't think there's any secret beyond > that. You have it exactly.? She wanted us (the Language Summit organizers) to keep the talk title a secret until she could reveal it herself in front of the audience.? I suggested the official title on the schedule be "Mariatta's Topic Of Mystery" and we collectively went with that.? At this point nothing about it is a secret. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Tue May 22 14:58:19 2018 From: barry at python.org (Barry Warsaw) Date: Tue, 22 May 2018 11:58:19 -0700 Subject: [python-committers] A different way to focus discussions Message-ID: [I think my other response got dropped, so apologies for any duplicates] Guido van Rossum wrote: > I wonder if it would make sense to require that for each PEP a new GitHub > *repo* be created whose contents would just be a draft PEP and whose issue > tracker and PR manager would be used to debate the PEP and propose specific > changes. I don't think I'd want to see tons of new PEP repos under the current `python` organization. Maybe we should create a new organization for this experiment? Also, since non-core devs can and do create PEPs, the permission management will be different than the normal repos. Clearly the PEP authors should be owners of the individual repos, but they should probably also decide how merges happen, and who else can contribute to their repo. It also means that PEP editors probably have an additional responsibility to create the PEP repo. PEP 1's Discussions-To header can probably be co-opted for the URL to the GH repo. Right now, that field is described as an email address, but it would be appropriate IMHO to also allow a URL for discussions. > Thoughts? (We can dogfood this proposal too, if there's interest. :-) I don't know whether this will help focus rambling PEP discussions. I personally don't love the linearity of GH comments. Threading is useful! OTOH, it seems like a low-cost experiment to try so if there's a volunteer who wants to be the guinea pig, I'm fine with it. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From antoine at python.org Tue May 22 15:07:43 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 22 May 2018 21:07:43 +0200 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org> Le 22/05/2018 ? 20:58, Barry Warsaw a ?crit?: > >> Thoughts? (We can dogfood this proposal too, if there's interest. :-) > > I don't know whether this will help focus rambling PEP discussions. I personally don't love the linearity of GH comments. Threading is useful! What has become of the Discourse experiment? Regards Antoine. From guido at python.org Tue May 22 15:44:33 2018 From: guido at python.org (Guido van Rossum) Date: Tue, 22 May 2018 12:44:33 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: On Tue, May 22, 2018 at 11:58 AM, Barry Warsaw wrote: > [I think my other response got dropped, so apologies for any duplicates] > > Guido van Rossum wrote: > > I wonder if it would make sense to require that for each PEP a new GitHub > > *repo* be created whose contents would just be a draft PEP and whose > issue > > tracker and PR manager would be used to debate the PEP and propose > specific > > changes. > > I don't think I'd want to see tons of new PEP repos under the current > `python` organization. Maybe we should create a new organization for this > experiment? > Hm, what's the cost of those extra repos? As long as they have consistent names (e.g. pep-1234) they're easy to ignore right? Or does GitHub have a quota of repos per org? > Also, since non-core devs can and do create PEPs, the permission > management will be different than the normal repos. Clearly the PEP > authors should be owners of the individual repos, but they should probably > also decide how merges happen, and who else can contribute to their repo. > > It also means that PEP editors probably have an additional responsibility > to create the PEP repo. > I was thinking of a workflow where the pep author initially creates the repo under their own username and directs discussion there. Then when their PEP is accepted (or rejected!) they can donate their repo to the python org. I know such a thing is possible (we did it for the mypy and typeshed repos). > PEP 1's Discussions-To header can probably be co-opted for the URL to the > GH repo. Right now, that field is described as an email address, but it > would be appropriate IMHO to also allow a URL for discussions. > Sure. > Thoughts? (We can dogfood this proposal too, if there's interest. :-) > > I don't know whether this will help focus rambling PEP discussions. I > personally don't love the linearity of GH comments. Threading is useful! > Ironically for me GitHub is less linear than email. It's easier to ask people to open a new issue than it is to ask them to start a new thread. So e.g. if a discussion starts about a survey of feature X in various languages, when it veers off into a tutorial for a specific language that could be a separate issue, and the meta-discussion on how the list of languages should be selected could be made another issue. > OTOH, it seems like a low-cost experiment to try so if there's a volunteer > who wants to be the guinea pig, I'm fine with it. > I think Mark Shannon volunteered PEP 576 (though so far he hasn't created a separate repo, he's just created a PR for the peps repo IIUC). I hope Nick will also volunteer PEP 577 for this. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Tue May 22 15:57:16 2018 From: vstinner at redhat.com (Victor Stinner) Date: Tue, 22 May 2018 21:57:16 +0200 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: Hi, 2018-05-19 7:45 GMT+02:00 Antoine Pitrou : > It would be *very* interesting if someone was willing to do some stats > on PEPs over time: e.g. number of PEPs discussed every year, discussion > length, number of discusssion participants. I actually expect overall > PEP activity to have gone down since the 2000s. I counted the number of emails per PEP (sent to python-dev or python-ideas) on the period Jan 2017 - April 2018: https://mail.python.org/pipermail/python-committers/2018-April/005310.html My script: https://github.com/vstinner/misc/blob/master/python/parse_mailman_mbox_peps.py I downloaded "[ Gzip'd Text 227 KB ]" links from https://mail.python.org/pipermail/python-dev/ and https://mail.python.org/pipermail/python-ideas/ and then uncompressed them. Victor From brett at python.org Tue May 22 16:06:33 2018 From: brett at python.org (Brett Cannon) Date: Tue, 22 May 2018 13:06:33 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org> References: <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org> Message-ID: On Tue, 22 May 2018 at 12:07 Antoine Pitrou wrote: > > Le 22/05/2018 ? 20:58, Barry Warsaw a ?crit : > > > >> Thoughts? (We can dogfood this proposal too, if there's interest. :-) > > > > I don't know whether this will help focus rambling PEP discussions. I > personally don't love the linearity of GH comments. Threading is useful! > > What has become of the Discourse experiment? > A Discourse experiment was never started. If you mean Zulip it's still going at python.zulipchat.com. > > 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: From antoine at python.org Tue May 22 16:09:50 2018 From: antoine at python.org (Antoine Pitrou) Date: Tue, 22 May 2018 22:09:50 +0200 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org> Message-ID: <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org> Le 22/05/2018 ? 22:06, Brett Cannon a ?crit?: > > > On Tue, 22 May 2018 at 12:07 Antoine Pitrou > wrote: > > > Le 22/05/2018 ? 20:58, Barry Warsaw a ?crit?: > > > >> Thoughts? (We can dogfood this proposal too, if there's interest. :-) > > > > I don't know whether this will help focus rambling PEP > discussions.? I personally don't love the linearity of GH comments.? > Threading is useful! > > What has become of the Discourse experiment? > > > A Discourse experiment was never started. If you mean Zulip it's still > going at python.zulipchat.com . I meant this, whatever it was: https://discuss.python.org/ :-) I don't think Zulip works for structured discussion. I also find it slightly less usable than I expected. Regards Antoine. From barry at python.org Tue May 22 16:52:21 2018 From: barry at python.org (Barry Warsaw) Date: Tue, 22 May 2018 13:52:21 -0700 Subject: [python-committers] A different way to focus discussions Message-ID: On May 22, 2018, at 12:44, Guido van Rossum wrote: > > Hm, what's the cost of those extra repos? As long as they have consistent names (e.g. pep-1234) they're easy to ignore right? Or does GitHub have a quota of repos per org? I think there is a quota for non-paying organizations, but I?m not sure. I was just thinking about clutter on https://github.com/python but maybe it won?t be so bad with? > I was thinking of a workflow where the pep author initially creates the repo under their own username and directs discussion there. Then when their PEP is accepted (or rejected!) they can donate their repo to the python org. I know such a thing is possible (we did it for the mypy and typeshed repos). ? +1! > Ironically for me GitHub is less linear than email. It's easier to ask people to open a new issue than it is to ask them to start a new thread. So e.g. if a discussion starts about a survey of feature X in various languages, when it veers off into a tutorial for a specific language that could be a separate issue, and the meta-discussion on how the list of languages should be selected could be made another issue. I see what you?re saying. Yes, that could work if the PEP author is really diligent about shunting detours into new issues. I?ve just found that within PRs or issues, the linearity can be quite difficult to follow. (FWIW, IMHO, GitLab does better here, but that?s besides the point.) > I think Mark Shannon volunteered PEP 576 (though so far he hasn't created a separate repo, he's just created a PR for the peps repo IIUC). I hope Nick will also volunteer PEP 577 for this. +1 -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP URL: From vstinner at redhat.com Tue May 22 17:50:48 2018 From: vstinner at redhat.com (Victor Stinner) Date: Tue, 22 May 2018 23:50:48 +0200 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: Hi, 2018-05-19 0:25 GMT+02:00 Guido van Rossum : > Discussing PEPs on python-dev and python-ideas is clearly not scalable any > more. (Even python-committers probably doesn't scale too well. :-) > > I wonder if it would make sense to require that for each PEP a new GitHub > *repo* be created whose contents would just be a draft PEP and whose issue > tracker and PR manager would be used to debate the PEP and propose specific > changes. Which problem do you want to solve? Reduce the number of emails per month on python-ideas and python-dev? Reduce the number of messages per PEP? If the number of messages per PEP is the problem, I don't see how replacing emails with GitHub would help. GitHub allows to add comments on: * commits * issues * pull requests Anyone can open new issues and new pull requests. It might be harder to follow discussions if they are occur at different parts of a single repository. I guess that your motivation is to prevent another PEP 572 mess. IMHO the discussions on the PEP 572 became a mess because nobody wanted to moderate the discussion. I asked on python-committers how to calm down the discussion, but no action has been taken and the flow of emails didn't stop. A moderator can try to summarize the discussion or can ask to stop discussing the PEP until the PEP is updated. For the PEP 572, it seems like a few issues have been spotted in the PEP, but I don't recall an email saying "these points must be fixed in the PEP, please wait until the PEP is updated". Will it be simpler to moderate discussions on GitHub? Or do you expect that less people will go to GitHub, than on python-dev/python-ideas, to discuss? I like emails because it's plain text, it's easily readable on all devices, there are archives (controlled by Python) which are readable online, etc. I also like threads in emails. It's easy to see if I missed messages. On GitHub, there is no markers of unread messages, only notifications (well, there are also notifications with messages ;-)). IMHO a PEP should summarize the most important discussed points. Otherwise, each time that someone who don't know the PEP will read it, the same discussion will restart from scratch. And I don't think that PEP 572 made that. > Thoughts? (We can dogfood this proposal too, if there's interest. :-) Apart the PEP 572, I recalled that I have been annoyed by the fspath protocol before a PEP has been written. I also recall that the discussions stopped when I asked to wait until Brett (and someone else, sorry I forgot) writes a PEP. For other PEPs, I think that the volume of emails is acceptable. I also like the idea of getting all PEPs in python-dev because it's easier for me to be aware of currently discussed PEPs, even if I don't read the discussions. But it seems like I'm getting old and resist to the shiny new GitHub which will solve all our issues ;-) Victor From donald at stufft.io Tue May 22 17:58:39 2018 From: donald at stufft.io (Donald Stufft) Date: Tue, 22 May 2018 17:58:39 -0400 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io> > On May 22, 2018, at 5:50 PM, Victor Stinner wrote: > > IMHO the discussions on the PEP 572 became a mess because nobody > wanted to moderate the discussion. I asked on python-committers how to > calm down the discussion, but no action has been taken and the flow of > emails didn't stop. FWIW, I think this is a key thing? Mailing lists are not easily moderatable. There?s no way to pause discussion, redirect, etc besides generating *more* email (and the tooling to do it is lackluster, it?s pretty much just asking people to do something, and hope everyone complies). Fracturing the discussion amongst multiple repos is one way of handling that, another option is better tooling for moderation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vstinner at redhat.com Tue May 22 18:09:43 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 23 May 2018 00:09:43 +0200 Subject: [python-committers] A different way to focus discussions In-Reply-To: <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io> References: <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io> Message-ID: 2018-05-22 23:58 GMT+02:00 Donald Stufft : > FWIW, I think this is a key thing? Mailing lists are not easily moderatable. > There?s no way to pause discussion, redirect, etc besides generating *more* > email (and the tooling to do it is lackluster, it?s pretty much just asking > people to do something, and hope everyone complies). Fracturing the > discussion amongst multiple repos is one way of handling that, another > option is better tooling for moderation. Another solution is to use Special Interest Group (SIG) mailing lists to discuss PEPs. distutils-sig accepted many PEPs which were never posted to python-dev. Someone told me that PEPs are not posted to python-dev to avoid restarting discussions from scratch ;-) I have been told when I asked why TOML has been chosen instead of YAML for a PEP ;-) It was maybe the PEP 518, I don't recall. Do we need a new more specific mailing lists to discuss PEPs changing the Python language? Or a generic noisy-pep mailing lists for PEPs with high traffic? :-) Victor From guido at python.org Tue May 22 20:21:53 2018 From: guido at python.org (Guido van Rossum) Date: Tue, 22 May 2018 17:21:53 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: On Tue, May 22, 2018 at 2:50 PM, Victor Stinner wrote: > 2018-05-19 0:25 GMT+02:00 Guido van Rossum : > > Discussing PEPs on python-dev and python-ideas is clearly not scalable > any > > more. (Even python-committers probably doesn't scale too well. :-) > > > > I wonder if it would make sense to require that for each PEP a new GitHub > > *repo* be created whose contents would just be a draft PEP and whose > issue > > tracker and PR manager would be used to debate the PEP and propose > specific > > changes. > > Which problem do you want to solve? Reduce the number of emails per > month on python-ideas and python-dev? Reduce the number of messages > per PEP? > Both. The lists have gotten out of hand, and it's clear that many people don't bother to read much of the discussion before posting an outraged response to something they disagree with. > If the number of messages per PEP is the problem, I don't see how > replacing emails with GitHub would help. GitHub allows to add comments > on: > > * commits > * issues > * pull requests > > Anyone can open new issues and new pull requests. It might be harder > to follow discussions if they are occur at different parts of a single > repository. > That's why I propose one repo per new PEP (or small cluster of related PEPs). I agree that just having one PR per PEP in the peps repo would not be an improvement. The single repo puts all related discussion together (all issues in that repo are about the same topic). This makes it easier for the PEP author to read all traffic related to their PEP without forcing them to read all of python-{ideas,dev}, while making it easier for others to create new threads (no worries that the PEP author won't see your comment). It also lets the PEP author effectively moderate the discussion (they can close issues and even delete off-topic messages). It also makes it possible for interested 3rd parties to read all traffic related to a repo (just subscribe to the repo). > I guess that your motivation is to prevent another PEP 572 mess. > > IMHO the discussions on the PEP 572 became a mess because nobody > wanted to moderate the discussion. I asked on python-committers how to > calm down the discussion, but no action has been taken and the flow of > emails didn't stop. > What action *can* you take on mailing lists like python-{ideas,dev}? > A moderator can try to summarize the discussion or can ask to stop > discussing the PEP until the PEP is updated. For the PEP 572, it seems > like a few issues have been spotted in the PEP, but I don't recall an > email saying "these points must be fixed in the PEP, please wait until > the PEP is updated". > > Will it be simpler to moderate discussions on GitHub? Or do you expect > that less people will go to GitHub, than on python-dev/python-ideas, > to discuss? > GitHub has superior moderation abilities over our mailing lists, plus the volume per topic (PEP or cluster of PEPs) is lower than the entire volume of python-{ideas,dev}. If it discourages drive-by comments by people not really invested in the discussion but eager to show off their opinions, well, that's just an added benefit. > I like emails because it's plain text, it's easily readable on all > devices, there are archives (controlled by Python) which are readable > online, etc. I also like threads in emails. It's easy to see if I > missed messages. On GitHub, there is no markers of unread messages, > only notifications (well, there are also notifications with messages > ;-)). > Maybe you should learn more about how to use GitHub? I find the experience superior, and I routinely keep up with it on my phone. > IMHO a PEP should summarize the most important discussed points. > Otherwise, each time that someone who don't know the PEP will read it, > the same discussion will restart from scratch. And I don't think that > PEP 572 made that. > That's an unreasonable requirement when the discussion gets out of hand like it got in that case. I hope to make it easier for the PEP author(s) to keep up in part so they will have an easier time summarizing (and won't be drawn into fruitless arguments as much by semi-troll comments). > > Thoughts? (We can dogfood this proposal too, if there's interest. :-) > > Apart the PEP 572, I recalled that I have been annoyed by the fspath > protocol before a PEP has been written. I also recall that the > discussions stopped when I asked to wait until Brett (and someone > else, sorry I forgot) writes a PEP. For other PEPs, I think that the > volume of emails is acceptable. > That was a long time ago. Note that the cluster around PEP 550 was #2 on your list, this was also fairly recent. I feel that traffic *in general* has been up (I routinely see threads on python-ideas now where I think "dumb idea" and mute the conversation). > I also like the idea of getting all PEPs in python-dev because it's > easier for me to be aware of currently discussed PEPs, even if I don't > read the discussions. > > But it seems like I'm getting old and resist to the shiny new GitHub > which will solve all our issues ;-) > To the contrary, *I* am getting old and I no longer have the energy to deal with mailing lists. Since most PEPs pass through my inbox, I hope I still have some say on how the discussion should be kept sane. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Tue May 22 21:06:20 2018 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 23 May 2018 11:06:20 +1000 Subject: [python-committers] A different way to focus discussions In-Reply-To: <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io> References: <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io> Message-ID: <20180523010620.GJ12683@ando.pearwood.info> On Tue, May 22, 2018 at 05:58:39PM -0400, Donald Stufft wrote: > > > On May 22, 2018, at 5:50 PM, Victor Stinner wrote: > > > > IMHO the discussions on the PEP 572 became a mess because nobody > > wanted to moderate the discussion. I asked on python-committers how to > > calm down the discussion, but no action has been taken and the flow of > > emails didn't stop. > > FWIW, I think this is a key thing? Mailing lists are not easily > moderatable. *Unmoderated* mailing lists are not easily moderated. > There?s no way to pause discussion, redirect, etc Does Github allow us to do these things? Not a rhetorical question. > besides > generating *more* email (and the tooling to do it is lackluster, it?s > pretty much just asking people to do something, and hope everyone > complies). Fracturing the discussion amongst multiple repos is one way > of handling that, another option is better tooling for moderation. It is one thing to identify a problem, another thing to state that something is a solution to that problem, and a completely different thing to actually solve the problem. How does fracturing the discussion help? One of the problems with PEP 372 was that the discussion was fractured across multiple threads on two mailing lists, leading to the same points being raised over and over again. (I think Chris was premature in taking it to Python-Dev while it was still be actively argued on Python-Ideas.) It seems to me that "fracturing the discussion amongst multiple repos" will have the same effect: increase the total volume, not decrease it, as well as increasing the chances that salient points will be missed. Am I wrong? As for better tooling for moderation, I asked earlier in this thread how moving to Github will help. What is this tooling? I think the problem with PEP 572 was that it was a perfect storm of a number of factors: - it relates to a feature simple enough that everyone has an opinion; - the statement/expression divide ("assignment is NOT an expression, and that's a feature!") has been a point of distinction between Python and "the competition" for 20+ years; - hence some very strong feelings; - legitimate concerns over complexity and the assign/equals bug; - bike-shedding and arguments over syntax; - distraction over unrelated proposal to change the way scoping works inside classes; - lots of newcomers to the community. I count at least three discussions about this on Reddit: https://redd.it/8fpv3f https://redd.it/8fokpw https://redd.it/8ex72p Most PEPs don't get even one. Trialling Github with a simpler, less emotional and bike-sheddy PEP may not demonstrate how well the process works when everyone and their pet cat has an opinion. -- Steve From willingc at gmail.com Tue May 22 21:17:00 2018 From: willingc at gmail.com (Carol Willing) Date: Tue, 22 May 2018 18:17:00 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: <4BF1AB56-A0F2-4E71-B96D-40B898FFDA7A@gmail.com> > On May 22, 2018, at 5:21 PM, Guido van Rossum > wrote: > > On Tue, May 22, 2018 at 2:50 PM, Victor Stinner > wrote: > 2018-05-19 0:25 GMT+02:00 Guido van Rossum >: > > Discussing PEPs on python-dev and python-ideas is clearly not scalable any > > more. (Even python-committers probably doesn't scale too well. :-) > > > > I wonder if it would make sense to require that for each PEP a new GitHub > > *repo* be created whose contents would just be a draft PEP and whose issue > > tracker and PR manager would be used to debate the PEP and propose specific > > changes. > > Which problem do you want to solve? Reduce the number of emails per > month on python-ideas and python-dev? Reduce the number of messages > per PEP? > > Both. The lists have gotten out of hand, and it's clear that many people don't bother to read much of the discussion before posting an outraged response to something they disagree with. > > If the number of messages per PEP is the problem, I don't see how > replacing emails with GitHub would help. GitHub allows to add comments > on: > > * commits > * issues > * pull requests > > Anyone can open new issues and new pull requests. It might be harder > to follow discussions if they are occur at different parts of a single > repository. > > That's why I propose one repo per new PEP (or small cluster of related PEPs). I agree that just having one PR per PEP in the peps repo would not be an improvement. > > The single repo puts all related discussion together (all issues in that repo are about the same topic). This makes it easier for the PEP author to read all traffic related to their PEP without forcing them to read all of python-{ideas,dev}, while making it easier for others to create new threads (no worries that the PEP author won't see your comment). It also lets the PEP author effectively moderate the discussion (they can close issues and even delete off-topic messages). It also makes it possible for interested 3rd parties to read all traffic related to a repo (just subscribe to the repo). > > I guess that your motivation is to prevent another PEP 572 mess. > > IMHO the discussions on the PEP 572 became a mess because nobody > wanted to moderate the discussion. I asked on python-committers how to > calm down the discussion, but no action has been taken and the flow of > emails didn't stop. > > What action *can* you take on mailing lists like python-{ideas,dev}? > > A moderator can try to summarize the discussion or can ask to stop > discussing the PEP until the PEP is updated. For the PEP 572, it seems > like a few issues have been spotted in the PEP, but I don't recall an > email saying "these points must be fixed in the PEP, please wait until > the PEP is updated". > > Will it be simpler to moderate discussions on GitHub? Or do you expect > that less people will go to GitHub, than on python-dev/python-ideas, > to discuss? > > GitHub has superior moderation abilities over our mailing lists, plus the volume per topic (PEP or cluster of PEPs) is lower than the entire volume of python-{ideas,dev}. > > If it discourages drive-by comments by people not really invested in the discussion but eager to show off their opinions, well, that's just an added benefit. > > I like emails because it's plain text, it's easily readable on all > devices, there are archives (controlled by Python) which are readable > online, etc. I also like threads in emails. It's easy to see if I > missed messages. On GitHub, there is no markers of unread messages, > only notifications (well, there are also notifications with messages > ;-)). > > Maybe you should learn more about how to use GitHub? I find the experience superior, and I routinely keep up with it on my phone. > > IMHO a PEP should summarize the most important discussed points. > Otherwise, each time that someone who don't know the PEP will read it, > the same discussion will restart from scratch. And I don't think that > PEP 572 made that. > > That's an unreasonable requirement when the discussion gets out of hand like it got in that case. I hope to make it easier for the PEP author(s) to keep up in part so they will have an easier time summarizing (and won't be drawn into fruitless arguments as much by semi-troll comments). > > > Thoughts? (We can dogfood this proposal too, if there's interest. :-) > > Apart the PEP 572, I recalled that I have been annoyed by the fspath > protocol before a PEP has been written. I also recall that the > discussions stopped when I asked to wait until Brett (and someone > else, sorry I forgot) writes a PEP. For other PEPs, I think that the > volume of emails is acceptable. > > That was a long time ago. Note that the cluster around PEP 550 was #2 on your list, this was also fairly recent. I feel that traffic *in general* has been up (I routinely see threads on python-ideas now where I think "dumb idea" and mute the conversation). > > I also like the idea of getting all PEPs in python-dev because it's > easier for me to be aware of currently discussed PEPs, even if I don't > read the discussions. > > But it seems like I'm getting old and resist to the shiny new GitHub > which will solve all our issues ;-) > > To the contrary, *I* am getting old and I no longer have the energy to deal with mailing lists. Since most PEPs pass through my inbox, I hope I still have some say on how the discussion should be kept sane. > > -- > --Guido van Rossum (python.org/~guido ) > _______________________________________________ > 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/ FWIW, I'm going to throw out some negotiation tips since most of what is happening before a PEP is approved or rejected is negotiation of some form. Ideally, I would like to add these to the dev guide in a checklist section for Feedback on PEPs. These are all research driven from Harvard. One-text principle (All parties work from the same document.) Setting ground rules for feedback on the text such as: - What is wrong with this draft as it is presented now? - Do you have important interests that this draft does not adequately address? Which ones? Why are they important? - What else seems wrong or is missing from the draft? Why are these things important? - Do you have other ideas for improvement? What are your reasons for suggesting these items? What key unmet interests do they address? - Do you have other ideas about how conflicting interests can be creatively and fairly resolved? - Understanding why you would like this particular interest met, but given that it has become clear that it is in direct conflict with other's interests, why should meeting your interest take priority over meeting theirs? What standards or fair process might we apply to deciding this? Keeping emotions from boiling over 1. Focus on your physical reaction. 2. Listen to what your counterpart is saying 3. Show you have heard them 4. Show some empathy. 5. Find out more. 6. Take a break. -------------- next part -------------- An HTML attachment was scrubbed... URL: From storchaka at gmail.com Wed May 23 07:45:23 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Wed, 23 May 2018 14:45:23 +0300 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: References: Message-ID: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> 15.05.18 14:51, Ned Deily ????: > This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your > feature fixes, bug fixes, and documentation updates in before > 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days > from now. We will then tag and produce the 3.7.0 release candidate. > Our goal continues been to be to have no changes between the release > candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 > BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are > no critical problems outstanding and that documentation for new > features in 3.7 is complete (including NEWS and What's New items), and > that 3.7 is getting exposure and tested with our various platorms and > third-party distributions and applications. Those of us who are > participating in the development sprints at PyCon US 2018 here in > Cleveland can feel the excitement building as we work through the > remaining issues, including completing the "What's New in 3.7" > document and final feature documentation. (We wish you could all be > here.) Is it possible to add yet one beta instead? CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release. From antoine at python.org Wed May 23 07:47:57 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 23 May 2018 13:47:57 +0200 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> Message-ID: <64f85804-e21d-c85d-d6f4-ba3a58cd231c@python.org> Also there's https://bugs.python.org/issue33612 which appears quite critical. Regards Antoine. Le 23/05/2018 ? 13:45, Serhiy Storchaka a ?crit?: > 15.05.18 14:51, Ned Deily ????: >> This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your >> feature fixes, bug fixes, and documentation updates in before >> 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days >> from now. We will then tag and produce the 3.7.0 release candidate. >> Our goal continues been to be to have no changes between the release >> candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 >> BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are >> no critical problems outstanding and that documentation for new >> features in 3.7 is complete (including NEWS and What's New items), and >> that 3.7 is getting exposure and tested with our various platorms and >> third-party distributions and applications. Those of us who are >> participating in the development sprints at PyCon US 2018 here in >> Cleveland can feel the excitement building as we work through the >> remaining issues, including completing the "What's New in 3.7" >> document and final feature documentation. (We wish you could all be >> here.) > > Is it possible to add yet one beta instead? > > CI was broken for few latest days, tests are not passed on my computer > still (and fail on some buildbots), updating What's New exposed new > features which need additional testing (and maybe fixing or reverting), > and I'm not comfortable about some changes which would be harder to fix > after the release. > _______________________________________________ > 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 vstinner at redhat.com Wed May 23 07:59:45 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 23 May 2018 13:59:45 +0200 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <64f85804-e21d-c85d-d6f4-ba3a58cd231c@python.org> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <64f85804-e21d-c85d-d6f4-ba3a58cd231c@python.org> Message-ID: 2018-05-23 13:47 GMT+02:00 Antoine Pitrou : > Also there's https://bugs.python.org/issue33612 which appears quite > critical. Can someone please have a look at my socketserver change? https://github.com/python/cpython/pull/6911 bpo-31151 changed ForkingMixIn and bpo-31233 changed ThreadingMixIn to block on server_closer() for processes/threads. I propose to add a new opt-in option to get the Python 3.6 behaviour. The old behaviour was wrong, but I expect that some people rely on it." https://bugs.python.org/issue33540 Victor From vstinner at redhat.com Wed May 23 08:16:14 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 23 May 2018 14:16:14 +0200 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> Message-ID: 2018-05-23 13:45 GMT+02:00 Serhiy Storchaka : > CI was broken for few latest days, tests are not passed on my computer still > (and fail on some buildbots), (...) I looked at buildbots and I confirm that many of the 3.x buildbots are red: AMD64 FreeBSD 10.x Shared 3.x AMD64 Windows8.1 Non-Debug 3.x ARMv7 Ubuntu 3.x PPC64 Fedora 3.x s390x RHEL 3.x x86 Gentoo Installed with X 3.x x86 Gentoo Refleaks 3.x AMD64 Windows8.1 Refleaks 3.x Victor From vstinner at redhat.com Wed May 23 08:21:38 2018 From: vstinner at redhat.com (Victor Stinner) Date: Wed, 23 May 2018 14:21:38 +0200 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> Message-ID: Ah, Python doesn't compile on Windows anymore :-) https://bugs.python.org/issue33614 Victor 2018-05-23 14:16 GMT+02:00 Victor Stinner : > 2018-05-23 13:45 GMT+02:00 Serhiy Storchaka : >> CI was broken for few latest days, tests are not passed on my computer still >> (and fail on some buildbots), (...) > > I looked at buildbots and I confirm that many of the 3.x buildbots are red: > > AMD64 FreeBSD 10.x Shared 3.x > AMD64 Windows8.1 Non-Debug 3.x > ARMv7 Ubuntu 3.x > PPC64 Fedora 3.x > s390x RHEL 3.x > x86 Gentoo Installed with X 3.x > x86 Gentoo Refleaks 3.x > AMD64 Windows8.1 Refleaks 3.x > > Victor From nad at python.org Wed May 23 09:13:53 2018 From: nad at python.org (Ned Deily) Date: Wed, 23 May 2018 09:13:53 -0400 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> Message-ID: On May 23, 2018, at 07:45, Serhiy Storchaka wrote: > 15.05.18 14:51, Ned Deily ????: >> This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your >> feature fixes, bug fixes, and documentation updates in before >> 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days >> from now. We will then tag and produce the 3.7.0 release candidate. >> Our goal continues been to be to have no changes between the release >> candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7 >> BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are >> no critical problems outstanding and that documentation for new >> features in 3.7 is complete (including NEWS and What's New items), and >> that 3.7 is getting exposure and tested with our various platorms and >> third-party distributions and applications. Those of us who are >> participating in the development sprints at PyCon US 2018 here in >> Cleveland can feel the excitement building as we work through the >> remaining issues, including completing the "What's New in 3.7" >> document and final feature documentation. (We wish you could all be >> here.) > Is it possible to add yet one beta instead? > > CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release. it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures. We have another 24 hours until rc1 was planned to be tagged. Let's keep working on the known issues and we will make a decision then. -- Ned Deily nad at python.org -- [] From ethan at stoneleaf.us Wed May 23 13:13:27 2018 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 23 May 2018 10:13:27 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: <20180523010620.GJ12683@ando.pearwood.info> References: <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io> <20180523010620.GJ12683@ando.pearwood.info> Message-ID: <5B05A137.3080903@stoneleaf.us> On 05/22/2018 06:06 PM, Steven D'Aprano wrote: > On Tue, May 22, 2018 at 05:58:39PM -0400, Donald Stufft wrote: >>> On May 22, 2018, at 5:50 PM, Victor Stinner wrote: > One of the problems with PEP 572 was that the discussion was fractured > across multiple threads on two mailing lists, leading to the same points > being raised over and over again. (I think Chris was premature in taking > it to Python-Dev while it was still be actively argued on Python-Ideas.) I have to take the blame for that. It looked to me like the PEP was as good as it was going to get on -ideas so I encouraged Chris to move it over to -dev. -- ~Ethan~ From nad at python.org Thu May 24 03:23:59 2018 From: nad at python.org (Ned Deily) Date: Thu, 24 May 2018 03:23:59 -0400 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> Message-ID: <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> On May 23, 2018, at 09:13, Ned Deily wrote: > On May 23, 2018, at 07:45, Serhiy Storchaka wrote: >> Is it possible to add yet one beta instead? >> CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release. > it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures. We have another 24 hours until rc1 was planned to be tagged. Let's keep working on the known issues and we will make a decision then. An update: thanks to a lot of effort over the past day by a number of people (including Victor, Serhiy, Christian, Zach, and others I'm sure I'm forgetting - my apologies), we have addressed all of the "release blocker" issues and all but one of the persistent failures on the 3.7 stable buildbots. We should have the couple of remaining "deferred blockers" including the remaining stable buildbots in green status by later today. At that point, we will be ready to tag 3.7.0rc1 and begin producing the release candidate artifacts. So this *is* really your last chance: if you know of any true releasing blocking issues for 3.7.0, you have about 12 more hours to log it in the bug tracker as a "release blocker". I'll send out an email once we start the release manufacturing. Any merges to the 3.7 branch after that will be released in 3.7.1 which we tentatively are planning to ship sometime before the end of July (< 2018-07-31). If you do find a critical problem in 3.7.0rc1 that you think needs to be fixed in 3.7.0, please merge a fix into 3.7 (and other appropriate branches), leave the issue open and marked as "release blocker", and add a note why you think the fix needs to be cherry-picked into 3.7.0. More later today! --Ned P.S. To address a few of the earlier comments on this thread: Antoine: > Also there's https://bugs.python.org/issue33612 which appears quite critical. Resolved Victor: > Can someone please have a look at my socketserver change? Reviewed and merged Victor: > I looked at buildbots and I confirm that many of the 3.x buildbots are red: Yes, but it's the 3.7 buildbots that are of interest now, not the 3.x ones :) And, as noted above, I believe we have cleaned up (or will shortly) the remaining 3.7 stable buildbot failures. Coincidentally, we've also fixed some of the 3.x (master -> 3.8) buildbots. Victor: > Ah, Python doesn't compile on Windows anymore :-) Stale files on one of the Windows buildbots -> cleaned up -- Ned Deily nad at python.org -- [] From nad at python.org Thu May 24 10:35:41 2018 From: nad at python.org (Ned Deily) Date: Thu, 24 May 2018 10:35:41 -0400 Subject: [python-committers] [Python-Dev] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> Message-ID: On May 24, 2018, at 07:26, Victor Stinner wrote: > 2018-05-24 9:23 GMT+02:00 Ned Deily : >> Any merges to the 3.7 branch after >> that will be released in 3.7.1 which we tentatively are planning to >> ship sometime before the end of July (< 2018-07-31). > I recall that Python 3.6.0 was full of bugs, some functions like > os.waitpid() on Windows (if I recall correctly) were completely > broken. > > We can do our best to test as much as possible, hope that more and > more people use the "nightly" Python version to run their CI, but we > always miss bugs. We always get the most testers when the final x.y.0 > version is released. > > Why waiting two months to release bugfixes? We're not planning on waiting two months. First, 3.7.0 final is not planned to release until 2018-06-15; if necessary, there could be one or more emergency bug fixes in it. Second, "before the end of July (< 2018-07-31)" does not mean we have to wait until the end of July. If necessary, it could be near the beginning of the month, so closer to two weeks after the release. Right now, our focus should be on getting high-quality 3.7.0rc1 and 3.7.0 final releases out there to our users and then we can focus on what comes next. Getting close! -- Ned Deily nad at python.org -- [] From storchaka at gmail.com Thu May 24 11:35:44 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Thu, 24 May 2018 18:35:44 +0300 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> Message-ID: 24.05.18 10:23, Ned Deily ????: > So this *is* really your last chance: if you know of any true releasing > blocking issues for 3.7.0, you have about 12 more hours to log it in > the bug tracker as a "release blocker". I'll send out an email once we > start the release manufacturing. Any merges to the 3.7 branch after > that will be released in 3.7.1 which we tentatively are planning to > ship sometime before the end of July (< 2018-07-31). If you do find a > critical problem in 3.7.0rc1 that you think needs to be fixed in 3.7.0, > please merge a fix into 3.7 (and other appropriate branches), leave the > issue open and marked as "release blocker", and add a note why you > think the fix needs to be cherry-picked into 3.7.0. I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it. 1. Changes in the AST. Few third-party projects was broken by it and already are fixed. I suppose yet few projects will be changed after 3.7 be released. It is interesting that IPython was broken in different way than other projects. It was needed to reintroduce the docstring in the list of statements, effectively reverting the 3.7 change. IPython allows to enter several statements at prompt, and therefore it compiles them with the 'exec' mode instead of 'single' as the CPython REPL and IDLE shell. Currently CPython doesn't allow you to paste arbitrary script like the following: if a: ??? b if c: ??? d You need to add an empty line between top-level complex statements. If one time CPython will add support of pasting several statements without empty lines between, it might need to add the same hack as IPython. I afraid that we might be needed to change AST again, in 3.7.1 or in 3.8.0. 2. Pickle support in typing is not perfect. I was going to fix it (I had almost ready code), but lost a chance of doing this before. It can be changed in 3.7.1, but this means that pickles of some derived typing types created in 3.7.0 will be not compatible with future versions (may be 3.7.1 will not break compatibility, but it will be broken in future because we will not specially supported compatibility with 3.7.0). There is third issue, related to NetBSD, but it is less important. I think two weeks will be enough for fixing these issues, but not at rc1 stage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Thu May 24 12:02:48 2018 From: nad at python.org (Ned Deily) Date: Thu, 24 May 2018 12:02:48 -0400 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> Message-ID: <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> On May 24, 2018, at 11:35, Serhiy Storchaka wrote: > I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it. [...] Serhiy, what are the bugs.python.org issue numbers for these? Are they marked as "release blocker"? -- Ned Deily nad at python.org -- [] From levkivskyi at gmail.com Thu May 24 12:25:51 2018 From: levkivskyi at gmail.com (Ivan Levkivskyi) Date: Thu, 24 May 2018 12:25:51 -0400 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> Message-ID: > 2. Pickle support in typing is not perfect. I was going to fix it (I had almost ready code), but lost a chance of doing this before. It can be changed in 3.7.1, but this means that pickles of some derived typing types created in 3.7.0 will be not compatible with future versions (may be 3.7.1 will not break compatibility, but it will be broken in future because we will not specially supported compatibility with 3.7.0). I think I had fixed this one. At least the examples reported on typing tracker are now fixed. Do you have some other examples that still fail? -- Ivan On 24 May 2018 at 12:02, Ned Deily wrote: > On May 24, 2018, at 11:35, Serhiy Storchaka wrote: > > I have doubts about two issues. I feel the responsibility for them > because I had the opportunity to solve them before, but I lost it. > [...] > > Serhiy, what are the bugs.python.org issue numbers for these? Are they > marked as "release blocker"? > > -- > Ned Deily > nad at python.org -- [] > > _______________________________________________ > 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: From storchaka at gmail.com Thu May 24 12:26:27 2018 From: storchaka at gmail.com (Serhiy Storchaka) Date: Thu, 24 May 2018 19:26:27 +0300 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> Message-ID: <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> 24.05.18 19:02, Ned Deily ????: > On May 24, 2018, at 11:35, Serhiy Storchaka wrote: >> I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it. > [...] > > Serhiy, what are the bugs.python.org issue numbers for these? Are they marked as "release blocker"? For docstring in AST: https://bugs.python.org/issue32911 Inada's patch looked complex (actually it mostly restored the code before his previous change). We didn't know about IPython and we decided that it is not worth to change this code at this stage (after beta2). And definitely it will be later to do this after rc1. For pickling of typing types: https://bugs.python.org/issue32873 Ivan fixed cases supported before 3.7. They now are backward and forward compatible. But cases not supported before 3.7 (like List[int]) now produce fragile pickles. From levkivskyi at gmail.com Thu May 24 12:42:27 2018 From: levkivskyi at gmail.com (Ivan Levkivskyi) Date: Thu, 24 May 2018 12:42:27 -0400 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> Message-ID: > But cases not supported before 3.7 (like List[int]) now produce fragile pickles. List[int] pickled in 3.7 can't be un-pickled in 3.6, but I wouldn't worry too much about this because it never worked in 3.6. I remember you proposed using __getitem__ in __reduce__, but I am not sure it is a better way, although it will fix the above problem. I don't think this one is a blocker and we can move this discussion back to b.p.o., unless you have some particular concerns. The AST one however looks more serious. -- Ivan On 24 May 2018 at 12:26, Serhiy Storchaka wrote: > 24.05.18 19:02, Ned Deily ????: > >> On May 24, 2018, at 11:35, Serhiy Storchaka wrote: >> >>> I have doubts about two issues. I feel the responsibility for them >>> because I had the opportunity to solve them before, but I lost it. >>> >> [...] >> >> Serhiy, what are the bugs.python.org issue numbers for these? Are they >> marked as "release blocker"? >> > > For docstring in AST: https://bugs.python.org/issue32911 > > Inada's patch looked complex (actually it mostly restored the code before > his previous change). We didn't know about IPython and we decided that it > is not worth to change this code at this stage (after beta2). And > definitely it will be later to do this after rc1. > > For pickling of typing types: https://bugs.python.org/issue32873 > > Ivan fixed cases supported before 3.7. They now are backward and forward > compatible. But cases not supported before 3.7 (like List[int]) now produce > fragile pickles. > > > _______________________________________________ > 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: From brett at python.org Thu May 24 12:54:19 2018 From: brett at python.org (Brett Cannon) Date: Thu, 24 May 2018 09:54:19 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org> References: <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org> <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org> Message-ID: On Tue, 22 May 2018 at 13:10 Antoine Pitrou wrote: > > Le 22/05/2018 ? 22:06, Brett Cannon a ?crit : > > > > > > On Tue, 22 May 2018 at 12:07 Antoine Pitrou > > wrote: > > > > > > Le 22/05/2018 ? 20:58, Barry Warsaw a ?crit : > > > > > >> Thoughts? (We can dogfood this proposal too, if there's interest. > :-) > > > > > > I don't know whether this will help focus rambling PEP > > discussions. I personally don't love the linearity of GH comments. > > Threading is useful! > > > > What has become of the Discourse experiment? > > > > > > A Discourse experiment was never started. If you mean Zulip it's still > > going at python.zulipchat.com . > > I meant this, whatever it was: https://discuss.python.org/ :-) > Ah, that never went anywhere because it was just a short experiment that the overload-sig did. If people wanted to do a serious experiment with it then we can discuss it over on core-workflow. > > I don't think Zulip works for structured discussion. I also find it > slightly less usable than I expected. > Why specifically? Do you still find IRC more usable? Just trying to understand how Discourse would be different enough to solve the issue you're having. -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: From brett at python.org Thu May 24 13:01:30 2018 From: brett at python.org (Brett Cannon) Date: Thu, 24 May 2018 10:01:30 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: <20180523010620.GJ12683@ando.pearwood.info> References: <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io> <20180523010620.GJ12683@ando.pearwood.info> Message-ID: On Tue, 22 May 2018 at 18:07 Steven D'Aprano wrote: > On Tue, May 22, 2018 at 05:58:39PM -0400, Donald Stufft wrote: > > > > > On May 22, 2018, at 5:50 PM, Victor Stinner > wrote: > > > > > > IMHO the discussions on the PEP 572 became a mess because nobody > > > wanted to moderate the discussion. I asked on python-committers how to > > > calm down the discussion, but no action has been taken and the flow of > > > emails didn't stop. > > > > FWIW, I think this is a key thing? Mailing lists are not easily > > moderatable. > > *Unmoderated* mailing lists are not easily moderated. > > > > There?s no way to pause discussion, redirect, etc > > Does Github allow us to do these things? Not a rhetorical question. > Locking/pausing issues and PRs yes (both temporarily and permanently), redirection not specifically beyond cross-referencing to another issue/PR in a comment. -Brett > > > > besides > > generating *more* email (and the tooling to do it is lackluster, it?s > > pretty much just asking people to do something, and hope everyone > > complies). Fracturing the discussion amongst multiple repos is one way > > of handling that, another option is better tooling for moderation. > > It is one thing to identify a problem, another thing to state that > something is a solution to that problem, and a completely different > thing to actually solve the problem. How does fracturing the discussion > help? > > One of the problems with PEP 372 was that the discussion was fractured > across multiple threads on two mailing lists, leading to the same points > being raised over and over again. (I think Chris was premature in taking > it to Python-Dev while it was still be actively argued on Python-Ideas.) > > It seems to me that "fracturing the discussion amongst multiple repos" > will have the same effect: increase the total volume, not decrease it, > as well as increasing the chances that salient points will be missed. Am > I wrong? > > As for better tooling for moderation, I asked earlier in this thread how > moving to Github will help. What is this tooling? > > > I think the problem with PEP 572 was that it was a perfect storm of a > number of factors: > > - it relates to a feature simple enough that everyone has an opinion; > > - the statement/expression divide ("assignment is NOT an expression, > and that's a feature!") has been a point of distinction between > Python and "the competition" for 20+ years; > > - hence some very strong feelings; > > - legitimate concerns over complexity and the assign/equals bug; > > - bike-shedding and arguments over syntax; > > - distraction over unrelated proposal to change the way scoping works > inside classes; > > - lots of newcomers to the community. > > I count at least three discussions about this on Reddit: > > https://redd.it/8fpv3f > https://redd.it/8fokpw > https://redd.it/8ex72p > > Most PEPs don't get even one. > > Trialling Github with a simpler, less emotional and bike-sheddy PEP may > not demonstrate how well the process works when everyone and their pet > cat has an opinion. > > > > -- > Steve > _______________________________________________ > 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: From nad at python.org Thu May 24 13:08:19 2018 From: nad at python.org (Ned Deily) Date: Thu, 24 May 2018 13:08:19 -0400 Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> Message-ID: On May 24, 2018, at 12:26, Serhiy Storchaka wrote: > 24.05.18 19:02, Ned Deily ????: >> On May 24, 2018, at 11:35, Serhiy Storchaka wrote: >>> I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it. >> [...] >> >> Serhiy, what are the bugs.python.org issue numbers for these? Are they marked as "release blocker"? > For docstring in AST: https://bugs.python.org/issue32911 > > Inada's patch looked complex (actually it mostly restored the code before his previous change). We didn't know about IPython and we decided that it is not worth to change this code at this stage (after beta2). And definitely it will be later to do this after rc1. We have had many discussions about this issue earlier and, while there were arguments made for more than one approach, I believe we reached agreement that this was a deliberate incompatibility that we and our users could live with. The issue has been closed since 2018-03-18. At some point, we need to move on. However, if additional exposure downstream has identified significant new problems, then the issue should be re-opened and a specific proposal made. BTW, do we know what the iPython folks think about this? But there still seems to be disagreements about whether anything needs to be changed. As I commented yesterday, I *really* don't want to keep revisiting this but I am not going to make a technical call. Without an open "release blocker" issue, though, nothing is going to change for 3.7.0rc1. If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue. > For pickling of typing types: https://bugs.python.org/issue32873 > > Ivan fixed cases supported before 3.7. They now are backward and forward compatible. But cases not supported before 3.7 (like List[int]) now produce fragile pickles. That issue was closed by Ivan and there have been no comments on it since 2018-04-04. I'll defer to his recent reply in this thread. -- Ned Deily nad at python.org -- [] From brett at python.org Thu May 24 12:56:01 2018 From: brett at python.org (Brett Cannon) Date: Thu, 24 May 2018 09:56:01 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: Message-ID: On Tue, 22 May 2018 at 13:52 Barry Warsaw wrote: > On May 22, 2018, at 12:44, Guido van Rossum wrote: > > > > Hm, what's the cost of those extra repos? As long as they have > consistent names (e.g. pep-1234) they're easy to ignore right? Or does > GitHub have a quota of repos per org? > > I think there is a quota for non-paying organizations, but I?m not sure. > I was just thinking about clutter on https://github.com/python but maybe > it won?t be so bad with? > I don't think there's a quota. -Brett > > > I was thinking of a workflow where the pep author initially creates the > repo under their own username and directs discussion there. Then when their > PEP is accepted (or rejected!) they can donate their repo to the python > org. I know such a thing is possible (we did it for the mypy and typeshed > repos). > > ? +1! > > > Ironically for me GitHub is less linear than email. It's easier to ask > people to open a new issue than it is to ask them to start a new thread. So > e.g. if a discussion starts about a survey of feature X in various > languages, when it veers off into a tutorial for a specific language that > could be a separate issue, and the meta-discussion on how the list of > languages should be selected could be made another issue. > > I see what you?re saying. Yes, that could work if the PEP author is > really diligent about shunting detours into new issues. I?ve just found > that within PRs or issues, the linearity can be quite difficult to follow. > (FWIW, IMHO, GitLab does better here, but that?s besides the point.) > You do realize you are very quickly volunteering to propose to write the PEP for moving issues to GitLab, right? ;) > > > I think Mark Shannon volunteered PEP 576 (though so far he hasn't > created a separate repo, he's just created a PR for the peps repo IIUC). I > hope Nick will also volunteer PEP 577 for this. > > +1 > > -Barry > _______________________________________________ > 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: From antoine at python.org Thu May 24 13:45:35 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 24 May 2018 19:45:35 +0200 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org> <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org> Message-ID: <178e4a00-184f-2622-6f98-c187ab9c178a@python.org> Le 24/05/2018 ? 18:54, Brett Cannon a ?crit?: > > I don't think Zulip works for structured discussion.? I also find it > slightly less usable than I expected. > > Why specifically? Do you still find IRC more usable? Um, no. But I find Zulip's way of grouping discussions by day *then* by topic makes things a bit confusing and not very easy to follow. It seems designed for people who log in every day. > Just trying to > understand how Discourse would be different enough to solve the issue > you're having. Which issue exactly? Zulip is decent as a chat system. It wouldn't really work for PEP discussions, IMO. That's why I asked about Discourse. Regards Antoine. From larry at hastings.org Thu May 24 13:46:27 2018 From: larry at hastings.org (Larry Hastings) Date: Thu, 24 May 2018 10:46:27 -0700 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> Message-ID: <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> On 05/24/2018 10:08 AM, Ned Deily wrote: > If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue. About that.? According to the Python Dev Guide: Whether a bug is a *release blocker* for the current release schedule is decided by the release manager. Triagers may recommend this priority and should add the release manager to the nosy list. https://devguide.python.org/triaging/#priority Of course, a particular release manager (e.g. Ned here) can change the policy for their releases.? But by default, unless you're the release manager for release X, you should not mark issues as "Release Blocker" for release X.? This seems like a sensible policy to me, and effective immediately I'm going to hold to this policy for my releases (3.4 and 3.5). //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Thu May 24 14:02:45 2018 From: brett at python.org (Brett Cannon) Date: Thu, 24 May 2018 11:02:45 -0700 Subject: [python-committers] A different way to focus discussions In-Reply-To: <178e4a00-184f-2622-6f98-c187ab9c178a@python.org> References: <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org> <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org> <178e4a00-184f-2622-6f98-c187ab9c178a@python.org> Message-ID: On Thu, 24 May 2018 at 10:45 Antoine Pitrou wrote: > > Le 24/05/2018 ? 18:54, Brett Cannon a ?crit : > > > > I don't think Zulip works for structured discussion. I also find it > > slightly less usable than I expected. > > > > Why specifically? Do you still find IRC more usable? > > Um, no. But I find Zulip's way of grouping discussions by day *then* by > topic makes things a bit confusing and not very easy to follow. It > seems designed for people who log in every day. > Ah, you must be reading Zulip through "All Messages". I personally read each topic individually by pressing "n" to navigate through each topic with an unread message, otherwise I too lose too much context. > > > Just trying to > > understand how Discourse would be different enough to solve the issue > > you're having. > > Which issue exactly? Zulip is decent as a chat system. It wouldn't > really work for PEP discussions, IMO. That's why I asked about Discourse. > Fair enough. Would you want a PEPs section and then some naming convention per thread to denote which PEP a thread is about? -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Thu May 24 14:05:09 2018 From: antoine at python.org (Antoine Pitrou) Date: Thu, 24 May 2018 20:05:09 +0200 Subject: [python-committers] A different way to focus discussions In-Reply-To: References: <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org> <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org> <178e4a00-184f-2622-6f98-c187ab9c178a@python.org> Message-ID: <6fff1d0e-b076-a289-d050-3c28b223b0dd@python.org> Le 24/05/2018 ? 20:02, Brett Cannon a ?crit?: > > Just trying to > > understand how Discourse would be different enough to solve the issue > > you're having. > > Which issue exactly?? Zulip is decent as a chat system.? It wouldn't > really work for PEP discussions, IMO.? That's why I asked about > Discourse. > > Fair enough. Would you want a PEPs section and then some naming > convention per thread to denote which PEP a thread is about? That could work. I'm not acquainted with Discourse, are there subsections? From donald at stufft.io Thu May 24 14:07:48 2018 From: donald at stufft.io (Donald Stufft) Date: Thu, 24 May 2018 14:07:48 -0400 Subject: [python-committers] A different way to focus discussions In-Reply-To: <6fff1d0e-b076-a289-d050-3c28b223b0dd@python.org> References: <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org> <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org> <178e4a00-184f-2622-6f98-c187ab9c178a@python.org> <6fff1d0e-b076-a289-d050-3c28b223b0dd@python.org> Message-ID: <7906134F-0D17-4157-BB01-58349394B330@stufft.io> > On May 24, 2018, at 2:05 PM, Antoine Pitrou wrote: > > > Le 24/05/2018 ? 20:02, Brett Cannon a ?crit : >>> Just trying to >>> understand how Discourse would be different enough to solve the issue >>> you're having. >> >> Which issue exactly? Zulip is decent as a chat system. It wouldn't >> really work for PEP discussions, IMO. That's why I asked about >> Discourse. >> >> Fair enough. Would you want a PEPs section and then some naming >> convention per thread to denote which PEP a thread is about? > > That could work. I'm not acquainted with Discourse, are there subsections? Yes, you can nest sections as deeply as you want, but the sections are typically static (I mean they can change over time, but making one per PEP would be a weird use of discourse). From nad at python.org Thu May 24 14:09:01 2018 From: nad at python.org (Ned Deily) Date: Thu, 24 May 2018 14:09:01 -0400 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> Message-ID: On May 24, 2018, at 13:46, Larry Hastings wrote: > On 05/24/2018 10:08 AM, Ned Deily wrote: >> If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue. > > About that. According to the Python Dev Guide: > Whether a bug is a *release blocker* for the current release schedule is decided by the release manager. Triagers may recommend this priority and should add the release manager to the nosy list. > > https://devguide.python.org/triaging/#priority > Of course, a particular release manager (e.g. Ned here) can change the policy for their releases. But by default, unless you're the release manager for release X, you should not mark issues as "Release Blocker" for release X. This seems like a sensible policy to me, and effective immediately I'm going to hold to this policy for my releases (3.4 and 3.5). I think we're reading the same words a bit differently. There's no question that the Release Manager makes the ultimate call whether an issue remains a "Release Blocker" or not. But it seems to me that the safest and most reliable way to ensure that the Release Manager makes that decision is by having a triager or submitter *provisionally* set the priority to "release blocker". It is then on the Release Manager's radar to accept or reject. I think that policy is totally in the spirit of the Dev Guide wording but I'm fine with other release managers accepting differing interpretations for their releases ;) As for 3.6.x and 3.7.x, I would much prefer to have too many proposed "release blocker" issues than to have too few. And the sooner they are reported, the better. -- Ned Deily nad at python.org -- [] From doko at ubuntu.com Thu May 24 17:04:02 2018 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 24 May 2018 23:04:02 +0200 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> Message-ID: <888c6cd4-3245-45ab-8222-f4d2e98cb516@ubuntu.com> On 24.05.2018 20:09, Ned Deily wrote: > On May 24, 2018, at 13:46, Larry Hastings wrote: >> On 05/24/2018 10:08 AM, Ned Deily wrote: >>> If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue. >> >> About that. According to the Python Dev Guide: >> Whether a bug is a *release blocker* for the current release schedule is decided by the release manager. Triagers may recommend this priority and should add the release manager to the nosy list. >> >> https://devguide.python.org/triaging/#priority >> Of course, a particular release manager (e.g. Ned here) can change the policy for their releases. But by default, unless you're the release manager for release X, you should not mark issues as "Release Blocker" for release X. This seems like a sensible policy to me, and effective immediately I'm going to hold to this policy for my releases (3.4 and 3.5). > > I think we're reading the same words a bit differently. There's no question that the Release Manager makes the ultimate call whether an issue remains a "Release Blocker" or not. But it seems to me that the safest and most reliable way to ensure that the Release Manager makes that decision is by having a triager or submitter *provisionally* set the priority to "release blocker". It is then on the Release Manager's radar to accept or reject. I think that policy is totally in the spirit of the Dev Guide wording but I'm fine with other release managers accepting differing interpretations for their releases ;) > > As for 3.6.x and 3.7.x, I would much prefer to have too many proposed "release blocker" issues than to have too few. And the sooner they are reported, the better. Ned's interpretation is the one I'm using for submitting such issues (maybe not twelve hours before a final release). What other documented ways would you have to get the attention of a release manager. Having different interpretations depending on the release manager doesn't look very practically. Matthias From nad at python.org Fri May 25 01:33:43 2018 From: nad at python.org (Ned Deily) Date: Fri, 25 May 2018 01:33:43 -0400 Subject: [python-committers] 3.7.0rc1 Delayed [was] FINAL WEEK FOR 3.7.0 CHANGES! In-Reply-To: <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> Message-ID: <45628031-F42C-4B3B-8B1C-F3BE3B49BBA6@python.org> On May 24, 2018, at 03:23, Ned Deily wrote: > On May 23, 2018, at 09:13, Ned Deily wrote: >> On May 23, 2018, at 07:45, Serhiy Storchaka wrote: >>> Is it possible to add yet one beta instead? >>> CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release. >> it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures. We have another 24 hours until rc1 was planned to be tagged. Let's keep working on the known issues and we will make a decision then. > An update: thanks to a lot of effort over the past day by a number of > people (including Victor, Serhiy, Christian, Zach, and others I'm sure > I'm forgetting - my apologies), we have addressed all of the "release > blocker" issues and all but one of the persistent failures on the 3.7 > stable buildbots. We should have the couple of remaining "deferred > blockers" including the remaining stable buildbots in green status by > later today. At that point, we will be ready to tag 3.7.0rc1 and begin > producing the release candidate artifacts. Further update: some good news and some changes. The good news is that we have resolutions for all of the previous release and deferred blockers. Thanks to a number of people for continuing to help get the remaining stable buildbot issues taken care of along with some lingering bugs. The not-quite-as-good news is that we have had more discussions about some unexpected incompatibilities that have shown up with downstream user testing with the AST docstrings changes in place (see bpo-32911). We have had some previous discussions about the expected user impact and, earlier in the beta phase, I encouraged us to stay the course with the feature as implemented. But I am now persuaded that we owe it to our users to take one more look at this to make sure we do not force them to make changes for 3.7 and then once again for 3.8. More details are in the bug tracker issue; I strongly encourage those of us who have been involved with this to "vote" there on the proposal to either (A) proceed with the release of the current implementation in 3.7.0 or (B) revert the feature in 3.7.0 and retarget for 3.8. Should the consensus be to revert (B), we will plan to have one more fast-track beta release (b5) prior to the release candidate, in order to allow downstream users to test their projects with the removal. PLEASE, keep the discussion about this on the bug tracker (and not here!) and keep it brief so we can move forward quickly. Because of the upcoming 3-day holiday weekend in some countries, I have set Tue 2018-05-29 18:00 UTC as a cutoff for "voting" but, if a clear consensus emerges earlier, we will likely cut the discussion short. So chime in now on the bug tracker if you have a stake in this issue. https://bugs.python.org/issue32911 This does mean that yesterday's "last chance" has been extended a bit, at most a few days. I will let you know as soon as we have made a decision about the feature and will provide updated 3.7.0 schedule info at that time. --Ned -- Ned Deily nad at python.org -- [] From ncoghlan at gmail.com Fri May 25 10:52:43 2018 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 26 May 2018 00:52:43 +1000 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> Message-ID: On 25 May 2018 at 04:09, Ned Deily wrote: > On May 24, 2018, at 13:46, Larry Hastings wrote: > > On 05/24/2018 10:08 AM, Ned Deily wrote: > >> If you (or anyone else) feels strongly enough about it, you should > re-open the issue now and make it as a "release blocker" and we should > discuss the implications and possible plans of action in the issue. > > > > About that. According to the Python Dev Guide: > > Whether a bug is a *release blocker* for the current release schedule is > decided by the release manager. Triagers may recommend this priority and > should add the release manager to the nosy list. > > > > https://devguide.python.org/triaging/#priority > > Of course, a particular release manager (e.g. Ned here) can change the > policy for their releases. But by default, unless you're the release > manager for release X, you should not mark issues as "Release Blocker" for > release X. This seems like a sensible policy to me, and effective > immediately I'm going to hold to this policy for my releases (3.4 and 3.5). > > I think we're reading the same words a bit differently. There's no > question that the Release Manager makes the ultimate call whether an issue > remains a "Release Blocker" or not. But it seems to me that the safest and > most reliable way to ensure that the Release Manager makes that decision is > by having a triager or submitter *provisionally* set the priority to > "release blocker". It is then on the Release Manager's radar to accept or > reject. I think that policy is totally in the spirit of the Dev Guide > wording but I'm fine with other release managers accepting differing > interpretations for their releases ;) > Right, my interpretation of that policy has been that to request RM review of a potential blocker I should: - set the status to Release Blocker - add the relevant RM to the nosy list - add a comment explaining why I think it might be a release blocker and asking the RM to take a look it at The RM then makes their decision by either commenting to say they're accepting the issue as a blocker, bumping it down to deferred blocker (if they don't think it's a blocker *yet*), or else bumping it down to one of the non-blocking priorities (if they don't agree that it's a blocker at all). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri May 25 11:26:11 2018 From: brett at python.org (Brett Cannon) Date: Fri, 25 May 2018 08:26:11 -0700 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> Message-ID: On Fri, May 25, 2018, 07:53 Nick Coghlan, wrote: > On 25 May 2018 at 04:09, Ned Deily wrote: > >> On May 24, 2018, at 13:46, Larry Hastings wrote: >> > On 05/24/2018 10:08 AM, Ned Deily wrote: >> >> If you (or anyone else) feels strongly enough about it, you should >> re-open the issue now and make it as a "release blocker" and we should >> discuss the implications and possible plans of action in the issue. >> > >> > About that. According to the Python Dev Guide: >> > Whether a bug is a *release blocker* for the current release schedule >> is decided by the release manager. Triagers may recommend this priority and >> should add the release manager to the nosy list. >> > >> > https://devguide.python.org/triaging/#priority >> > Of course, a particular release manager (e.g. Ned here) can change the >> policy for their releases. But by default, unless you're the release >> manager for release X, you should not mark issues as "Release Blocker" for >> release X. This seems like a sensible policy to me, and effective >> immediately I'm going to hold to this policy for my releases (3.4 and 3.5). >> >> I think we're reading the same words a bit differently. There's no >> question that the Release Manager makes the ultimate call whether an issue >> remains a "Release Blocker" or not. But it seems to me that the safest and >> most reliable way to ensure that the Release Manager makes that decision is >> by having a triager or submitter *provisionally* set the priority to >> "release blocker". It is then on the Release Manager's radar to accept or >> reject. I think that policy is totally in the spirit of the Dev Guide >> wording but I'm fine with other release managers accepting differing >> interpretations for their releases ;) >> > > Right, my interpretation of that policy has been that to request RM review > of a potential blocker I should: > > - set the status to Release Blocker > - add the relevant RM to the nosy list > - add a comment explaining why I think it might be a release blocker and > asking the RM to take a look it at > > The RM then makes their decision by either commenting to say they're > accepting the issue as a blocker, bumping it down to deferred blocker (if > they don't think it's a blocker *yet*), or else bumping it down to one of > the non-blocking priorities (if they don't agree that it's a blocker at > all). > That's how I've always done it as well. As Ned said, better safe than sorry by guessing at something being a release blocker than something accidentally being lost in the cracks. > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > _______________________________________________ > 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: From brett at python.org Fri May 25 13:43:21 2018 From: brett at python.org (Brett Cannon) Date: Fri, 25 May 2018 10:43:21 -0700 Subject: [python-committers] Quick reminder: please don't push long-lived dev branches to the CPython repo Message-ID: If you create a dev branch that is going to live for less than 24 hours because you edited some typo in the docs or something through GitHub's UI, then that's fine. But long-lived dev branches should be done in one's personal fork. This is for two reasons: one is so that others don't inadvertently download your dev branch when they do a `git pull` (and because people often forget to do `git pull --prune`), and two because it eats up our CI (which is especially precious while we are still on AppVeyor and the turn-around time there is so long). -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Fri May 25 16:19:18 2018 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 25 May 2018 16:19:18 -0400 Subject: [python-committers] Quick reminder: please don't push long-lived dev branches to the CPython repo In-Reply-To: References: Message-ID: <5cd515f5-4efe-544c-0fe8-7672bc08caa3@udel.edu> On 5/25/2018 1:43 PM, Brett Cannon wrote: > If you create a dev branch that is going to live for less than 24 hours > because you edited some typo in the docs or something through GitHub's > UI, then that's fine. But long-lived dev branches should be done in > one's personal fork. This is for two reasons: one is so that others > don't inadvertently download your dev branch when they do a `git pull` > (and because people often forget to do `git pull --prune`), --prune is not mentioned on https://devguide.python.org/gitbootcamp/ and two > because it eats up our CI (which is especially precious while we are > still on AppVeyor and the turn-around time there is so long). From steve.dower at python.org Fri May 25 17:01:10 2018 From: steve.dower at python.org (Steve Dower) Date: Fri, 25 May 2018 14:01:10 -0700 Subject: [python-committers] Quick reminder: please don't push long-lived dev branches to the CPython repo In-Reply-To: References: Message-ID: On 25May2018 1043, Brett Cannon wrote: > (and because people often forget to do `git pull --prune`), and two > because it eats up our CI (which is especially precious while we are > still on AppVeyor and the turn-around time there is so long). Don't we have branch filters on CI? (I certainly put them on the VSTS builds, and I thought they were there on AppVeyor/Travis too.) Cheers, Steve From brett at python.org Mon May 28 12:19:04 2018 From: brett at python.org (Brett Cannon) Date: Mon, 28 May 2018 09:19:04 -0700 Subject: [python-committers] Quick reminder: please don't push long-lived dev branches to the CPython repo In-Reply-To: References: Message-ID: On Fri, 25 May 2018 at 14:01 Steve Dower wrote: > On 25May2018 1043, Brett Cannon wrote: > > (and because people often forget to do `git pull --prune`), and two > > because it eats up our CI (which is especially precious while we are > > still on AppVeyor and the turn-around time there is so long). > > Don't we have branch filters on CI? (I certainly put them on the VSTS > builds, and I thought they were there on AppVeyor/Travis too.) > We have filters for Travis, not sure about AppVeyor. I think the branch that triggered this was also immediately opened as a PR and pushing to the branch updates the PR and so that also didn't help matters either. But regardless, making everyone download the branch is still a bit annoying -Brett > > Cheers, > Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Mon May 28 13:47:56 2018 From: nad at python.org (Ned Deily) Date: Mon, 28 May 2018 13:47:56 -0400 Subject: [python-committers] [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch In-Reply-To: References: <163a70fca60.27a3.db5b03704c129196a4e9415e55413ce6@gmail.com> Message-ID: <821FDA20-E5F6-4650-8754-DD77A909DB5A@python.org> On May 28, 2018, at 13:19, Nathaniel Smith wrote: > > Isn't that what happens if someone enables the check box at Repository Settings -> Branches -> Branch protection rules -> [pick a branch] -> Require branches to be up to date before merging ? Hmm, for some some reason, it appears that, at the moment, the 2.7, 3.4, and 3.5 branches have that option set, while 3.6, 3.7, and master don't. I'm not sure how we got to that state. Any other reasons to prefer on versus off? On Mon, May 28, 2018, 09:11 Brett Cannon wrote: > Ryan is right that there's no special setting in GitHub at least which would make merging more strict for certain branches as you're describing. > > On Mon, 28 May 2018 at 07:06 Ryan Gonzalez wrote: > AFAIK there's no setting like this available, and I've done this many times > on other repos with no trouble. Maybe it could be a GitHub bug? > > On May 28, 2018 4:59:03 AM Victor Stinner wrote: > > > Hi, > > > > Since one or two weeks, I noticed that it's difficult to merge pull > > requests into the 2.7 branch. If a different commit is pushed in the > > meanwhile (if a different PR has been merged), the 2.7 branch diverges > > and the PR is immediately marked as "This branch is out-of-date with > > the base branch" and the "Squash and Merge" button is disabled (grey). > > > > For example my PR https://github.com/python/cpython/pull/7120 which > > changes Lib/test/regrtest.py cannot be merged because a commit > > touching the documentation (Doc/ directory) has been merged after I > > posted my PR and before the CI completed. > > > > I don't see the same behavior on the master branch. Is the 2.7 branch > > configured as more strict? -- Ned Deily nad at python.org -- [] From nad at python.org Tue May 29 12:11:12 2018 From: nad at python.org (Ned Deily) Date: Tue, 29 May 2018 12:11:12 -0400 Subject: [python-committers] Python 3.7.0 updated schedule: beta 5 cutoff in 24 hours Message-ID: <333C2C43-459C-46C4-A3AE-637FA05D0057@python.org> Here's an update on the 3.7.0 endgame. As announced several days ago, we made the difficult decision to hold back on 3.7.0rc1 due primarily to some unexpected difficulties being seen downstream due to changes in how docstrings were handled in 3.7.0 (details below). After some discussions about various approaches, we agreed on a solution that should minimize downstream impact without losing all the benefits of the existing 3.7 changes. Thanks to a lot of work over the long weekend by a number of people that solution is now merged in the 3.7 branch. In parallel with that, a number of people spent a lot of time looking at CI and buildbot test failures, mostly intermittent ones. As a result, a number of actual bugs were fixed and also problems with a number of tests were fixed which should make the test suite more robust. All this is good news. Primarily because of the important user-facing changes made with the AST docstring API, I feel we need to do one more beta release before we are ready for the release candidate. About 24 hours from now, approximately 2018-05-30 18:00UTC, I plan to tag and start manufacturing 3.7.0b5. This will be a short beta cycle, aimed mainly at users of the AST API so they can recheck that their packages with 3.7.0. Assuming all goes well, we will then plan to tag 3.7.0rc1 on 2018-06-11 and 3.7.0 final on 2017-06-27. I am also rescheduling 3.6.6rc1 and 3.6.6 final to match the new 3.7.0 dates. All fixes that have been merged into the 3.7 branch as of cutoff tomorrow will be in 3.7.0b5 and fixes merged afterwards will be in 3.7.0rc1 up to its cutoff point. After 3.7.0rc1 cutoff, 3.7 merges will appear in 3.7.1. Please continue to exercise diligence when deciding whether a change is appropriate for 3.7; as a rule of thumb, treat the 3.7 branch as if it were already released and in maintenance mode. Please also pay attention to CI test failures and buildbot test failures and see if you can help resolve them. I want to thank everyone who has been involved so far in helping us through this endgame and who have given up their personal time to work on making Python better. I, for one, am deeply grateful. 2018-05-30 3.7.0b5 2018-06-11 3.7.0rc1 & 3.6.6rc1 2018-06-27 3.7.0final & 3.6.6final --Ned On May 25, 2018, at 01:33, Ned Deily wrote: > On May 24, 2018, at 03:23, Ned Deily wrote: >> On May 23, 2018, at 09:13, Ned Deily wrote: >>> On May 23, 2018, at 07:45, Serhiy Storchaka wrote: >>>> Is it possible to add yet one beta instead? >>>> CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release. >>> it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures. We have another 24 hours until rc1 was planned to be tagged. Let's keep working on the known issues and we will make a decision then. >> An update: thanks to a lot of effort over the past day by a number of >> people (including Victor, Serhiy, Christian, Zach, and others I'm sure >> I'm forgetting - my apologies), we have addressed all of the "release >> blocker" issues and all but one of the persistent failures on the 3.7 >> stable buildbots. We should have the couple of remaining "deferred >> blockers" including the remaining stable buildbots in green status by >> later today. At that point, we will be ready to tag 3.7.0rc1 and begin >> producing the release candidate artifacts. > Further update: some good news and some changes. > > The good news is that we have resolutions for all of the previous release and deferred blockers. Thanks to a number of people for continuing to help get the remaining stable buildbot issues taken care of along with some lingering bugs. > > The not-quite-as-good news is that we have had more discussions about some unexpected incompatibilities that have shown up with downstream user testing with the AST docstrings changes in place (see bpo-32911). We have had some previous discussions about the expected user impact and, earlier in the beta phase, I encouraged us to stay the course with the feature as implemented. But I am now persuaded that we owe it to our users to take one more look at this to make sure we do not force them to make changes for 3.7 and then once again for 3.8. More details are in the bug tracker issue; I strongly encourage those of us who have been involved with this to "vote" there on the proposal to either (A) proceed with the release of the current implementation in 3.7.0 or (B) revert the feature in 3.7.0 and retarget for 3.8. Should the consensus be to revert (B), we will plan to have one more fast-track beta release (b5) prior to the release candidate, in order to allow downstream users to tes > t their projects with the removal. PLEASE, keep the discussion about this on the bug tracker (and not here!) and keep it brief so we can move forward quickly. Because of the upcoming 3-day holiday weekend in some countries, I have set Tue 2018-05-29 18:00 UTC as a cutoff for "voting" but, if a clear consensus emerges earlier, we will likely cut the discussion short. So chime in now on the bug tracker if you have a stake in this issue. > > https://bugs.python.org/issue32911 > > This does mean that yesterday's "last chance" has been extended a bit, at most a few days. I will let you know as soon as we have made a decision about the feature and will provide updated 3.7.0 schedule info at that time. -- Ned Deily nad at python.org -- [] From rdmurray at bitdance.com Tue May 29 17:45:29 2018 From: rdmurray at bitdance.com (R. David Murray) Date: Tue, 29 May 2018 17:45:29 -0400 Subject: [python-committers] Triage perms for Elvis Message-ID: <20180529214529.AFA0F251783@webabinitio.net> At Yuri's request I've given Elvis triage privileges on the tracker. I don't anticipate any objections, given the work he's done on What's New and other things. --David From nad at python.org Tue May 29 17:53:38 2018 From: nad at python.org (Ned Deily) Date: Tue, 29 May 2018 17:53:38 -0400 Subject: [python-committers] Triage perms for Elvis In-Reply-To: <20180529214529.AFA0F251783@webabinitio.net> References: <20180529214529.AFA0F251783@webabinitio.net> Message-ID: <26EB5121-4F52-42C7-8567-DA3116701A22@python.org> On May 29, 2018, at 17:45, R. David Murray wrote: > At Yuri's request I've given Elvis triage privileges on the tracker. > I don't anticipate any objections, given the work he's done on > What's New and other things. +1 Thanks! -- Ned Deily nad at python.org -- [] From christian at python.org Tue May 29 18:05:56 2018 From: christian at python.org (Christian Heimes) Date: Wed, 30 May 2018 00:05:56 +0200 Subject: [python-committers] Triage perms for Elvis In-Reply-To: <20180529214529.AFA0F251783@webabinitio.net> References: <20180529214529.AFA0F251783@webabinitio.net> Message-ID: <580b305c-e126-4949-ae93-443051f7ee61@python.org> On 2018-05-29 23:45, R. David Murray wrote: > At Yuri's request I've given Elvis triage privileges on the tracker. > I don't anticipate any objections, given the work he's done on > What's New and other things. +1 From lukasz at langa.pl Tue May 29 20:54:58 2018 From: lukasz at langa.pl (Lukasz Langa) Date: Tue, 29 May 2018 17:54:58 -0700 Subject: [python-committers] Triage perms for Elvis In-Reply-To: <20180529214529.AFA0F251783@webabinitio.net> References: <20180529214529.AFA0F251783@webabinitio.net> Message-ID: <1C2646A2-1956-44F1-A524-FD694276CEBD@langa.pl> +1 > On May 29, 2018, at 2:45 PM, R. David Murray wrote: > > At Yuri's request I've given Elvis triage privileges on the tracker. > I don't anticipate any objections, given the work he's done on > What's New and other things. > > --David > _______________________________________________ > 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 andrew.svetlov at gmail.com Wed May 30 03:12:28 2018 From: andrew.svetlov at gmail.com (Andrew Svetlov) Date: Wed, 30 May 2018 10:12:28 +0300 Subject: [python-committers] Triage perms for Elvis In-Reply-To: <1C2646A2-1956-44F1-A524-FD694276CEBD@langa.pl> References: <20180529214529.AFA0F251783@webabinitio.net> <1C2646A2-1956-44F1-A524-FD694276CEBD@langa.pl> Message-ID: +1 On Wed, May 30, 2018 at 3:54 AM Lukasz Langa wrote: > +1 > > > On May 29, 2018, at 2:45 PM, R. David Murray > wrote: > > > > At Yuri's request I've given Elvis triage privileges on the tracker. > > I don't anticipate any objections, given the work he's done on > > What's New and other things. > > > > --David > > _______________________________________________ > > 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/ > -- Thanks, Andrew Svetlov -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Wed May 30 13:15:04 2018 From: larry at hastings.org (Larry Hastings) Date: Wed, 30 May 2018 10:15:04 -0700 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> Message-ID: Well, I must admit, I'm a little baffled.? The text states unequivocally that the release manager is the only person who decides whether or not a bug is a "release blocker".? This means nobody else is permitted to make this decision.? So I don't see how somebody else can mark a bug as a "release blocker" without first deciding that it's a "release blocker"--which they're not permitted to do given the rules laid down by the Dev Guide. But if that's not the intended Core Dev policy, then that's not the intended Core Dev policy.? Given that literally everybody else interpreted the text differently than me, this suggests that the text is at the very least ambiguous, if not outright misleading and should be updated.? I'll try to put together a PR to bring it more in line with everyone's de facto interpretation. BTW, this all came up because a core dev marked a minor documentation change as a "release blocker" for the 3.5 branch, stating that they did this "because it'd be nice to see it make it out in the next release".? ISTM that opinions vary on what constitutes a "release blocker", and maybe empowering only the release managers to make that call would be a good way forward--which is what ISTM is what the Dev Guide already says anyway.? But I guess not! //arry/ On 05/25/2018 08:26 AM, Brett Cannon wrote: > > > On Fri, May 25, 2018, 07:53 Nick Coghlan, > wrote: > > On 25 May 2018 at 04:09, Ned Deily > wrote: > > On May 24, 2018, at 13:46, Larry Hastings > wrote: > > On 05/24/2018 10:08 AM, Ned Deily wrote: > >> If you (or anyone else) feels strongly enough about it, you > should re-open the issue now and make it as a "release > blocker" and we should discuss the implications and possible > plans of action in the issue. > > > > About that.? According to the Python Dev Guide: > > Whether a bug is a *release blocker* for the current release > schedule is decided by the release manager. Triagers may > recommend this priority and should add the release manager to > the nosy list. > > > > https://devguide.python.org/triaging/#priority > > Of course, a particular release manager (e.g. Ned here) can > change the policy for their releases. But by default, unless > you're the release manager for release X, you should not mark > issues as "Release Blocker" for release X.? This seems like a > sensible policy to me, and effective immediately I'm going to > hold to this policy for my releases (3.4 and 3.5). > > I think we're reading the same words a bit differently.? > There's no question that the Release Manager makes the > ultimate call whether an issue remains a "Release Blocker" or > not.? But it seems to me that the safest and most reliable way > to ensure that the Release Manager makes that decision is by > having a triager or submitter *provisionally* set the priority > to "release blocker".? It is then on the Release Manager's > radar to accept or reject.? I think that policy is totally in > the spirit of the Dev Guide wording but I'm fine with other > release managers accepting differing interpretations for their > releases ;) > > > Right, my interpretation of that policy has been that to request > RM review of a potential blocker I should: > > - set the status to Release Blocker > - add the relevant RM to the nosy list > - add a comment explaining why I think it might be a release > blocker and asking the RM to take a look it at > > The RM then makes their decision by either commenting to say > they're accepting the issue as a blocker, bumping it down to > deferred blocker (if they don't think it's a blocker *yet*), or > else bumping it down to one of the non-blocking priorities (if > they don't agree that it's a blocker at all). > > > That's how I've always done it as well. As Ned said, better safe than > sorry by guessing at something being a release blocker than something > accidentally being lost in the cracks. > > > > Cheers, > Nick. > > -- > Nick Coghlan?? | ncoghlan at gmail.com ?? > | Brisbane, Australia > _______________________________________________ > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Wed May 30 13:21:40 2018 From: donald at stufft.io (Donald Stufft) Date: Wed, 30 May 2018 13:21:40 -0400 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> Message-ID: <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io> > On May 30, 2018, at 1:15 PM, Larry Hastings wrote: > > ISTM that opinions vary on what constitutes a "release blocker", and maybe empowering only the release managers to make that call would be a good way forward--which is what ISTM is what the Dev Guide already says anyway. But I guess not! I think that RMs are empowered to decide what is a ?real" release blocker, but you need some mechanism to flag an issue as potentially a release blocker for the RM to make a decision on it. Making a decision on that potentially release blocker should also itself be a release blocker (because if it?s possibly a release blocker, then we should treat it as such until the person empowered to make that call has decided one way or another). So I think for the system to work, you need to either allow anyone to flag an issue as a release blocker, and the RM is empowered to say ?No this really isn?t? and unflag it, or you need two flags, for release blocker, and maybe release blocker, and both block the release. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mal at egenix.com Wed May 30 13:46:54 2018 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 30 May 2018 19:46:54 +0200 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io> Message-ID: In terms of process, it's always good to have a method to escalate a question to higher management in a way which doesn't require the manager to first parse long text messages. So a status such as "Potential Release Blocker" or "RM Review" sounds like a good way forward. Of course a friendly ping via some other channel usually also helps get attention :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 30 2018) >>> 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 larry at hastings.org Wed May 30 15:03:59 2018 From: larry at hastings.org (Larry Hastings) Date: Wed, 30 May 2018 12:03:59 -0700 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io> Message-ID: On 05/30/2018 10:21 AM, Donald Stufft wrote: > >> On May 30, 2018, at 1:15 PM, Larry Hastings > > wrote: >> >> ISTM that opinions vary on what constitutes a "release blocker", and >> maybe empowering only the release managers to make that call would be >> a good way forward--which is what ISTM is what the Dev Guide already >> says anyway.? But I guess not! > > I think that RMs are empowered to decide what is a ?real" release > blocker, but you need some mechanism to flag an issue as potentially a > release blocker for the RM to make a decision on it. Making a decision > on that potentially release blocker should also itself be a release > blocker (because if it?s possibly a release blocker, then we should > treat it as such until the person empowered to make that call has > decided one way or another). > > So I think for the system to work, you need to either allow anyone to > flag an issue as a release blocker, and the RM is empowered to say ?No > this really isn?t? and unflag it, or you need two flags, for release > blocker, and maybe release blocker, and both block the release. Yes, ISTM that the Dev Guide covers this.? The section on priority says: Triagers may recommend this priority and should add the release manager to the nosy list. In other words: if a dev thinks an issue should be a release blocker for version X, they should add the RM to the nosy list and make a comment recommending the issue be escalated to release blocker.? I thought it was telling that it /doesn't/ instruct triagers to mark the issue as a release blocker themselves. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed May 30 14:59:01 2018 From: brett at python.org (Brett Cannon) Date: Wed, 30 May 2018 11:59:01 -0700 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io> Message-ID: On Wed, 30 May 2018 at 10:21 Donald Stufft wrote: > > On May 30, 2018, at 1:15 PM, Larry Hastings wrote: > > ISTM that opinions vary on what constitutes a "release blocker", and maybe > empowering only the release managers to make that call would be a good way > forward--which is what ISTM is what the Dev Guide already says anyway. But > I guess not! > > > I think that RMs are empowered to decide what is a ?real" release blocker, > but you need some mechanism to flag an issue as potentially a release > blocker for the RM to make a decision on it. Making a decision on that > potentially release blocker should also itself be a release blocker > (because if it?s possibly a release blocker, then we should treat it as > such until the person empowered to make that call has decided one way or > another). > And this is how I have always interpreted it. Larry is totally within his rights to say "that is not a release blocker" and switch it to not being one. At the end of the day it's Larry who presses the proverbial "Release" button and that label technically means nothing if he chooses to ignore it. > > So I think for the system to work, you need to either allow anyone to flag > an issue as a release blocker, and the RM is empowered to say ?No this > really isn?t? and unflag it, or you need two flags, for release blocker, > and maybe release blocker, and both block the release. > Yep, or as MAL suggested, a "potential release blocker" or something where we expect only RMs to push something all the way up to an actual "release blocker". -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Wed May 30 15:07:41 2018 From: larry at hastings.org (Larry Hastings) Date: Wed, 30 May 2018 12:07:41 -0700 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io> Message-ID: <743f53c3-46d9-5ec8-55c6-bfe4a0562978@hastings.org> On 05/30/2018 11:59 AM, Brett Cannon wrote: > On Wed, 30 May 2018 at 10:21 Donald Stufft > wrote: > > > So I think for the system to work, you need to either allow anyone > to flag an issue as a release blocker, and the RM is empowered to > say ?No this really isn?t? and unflag it, or you need two flags, > for release blocker, and maybe release blocker, and both block the > release. > > > Yep, or as MAL suggested, a "potential release blocker" or something > where we expect only RMs to push something all the way up to an actual > "release blocker". I suggest we simply use the existing "critical" priority to also mean "potential release blocker".? If not, what would be the salient difference between a "critical" bug and a "potential release blocker" bug? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Wed May 30 15:09:22 2018 From: donald at stufft.io (Donald Stufft) Date: Wed, 30 May 2018 15:09:22 -0400 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io> Message-ID: <7D500DE9-1196-465A-BBC5-89652BC6D3CE@stufft.io> > On May 30, 2018, at 3:03 PM, Larry Hastings wrote: > > Yes, ISTM that the Dev Guide covers this. The section on priority says: > Triagers may recommend this priority and should add the release manager to the nosy list. > In other words: if a dev thinks an issue should be a release blocker for version X, they should add the RM to the nosy list and make a comment recommending the issue be escalated to release blocker. I thought it was telling that it doesn't instruct triagers to mark the issue as a release blocker themselves. That seems a rather poor way of handling it TBH. A key thing is that an escalation for a decision should itself be a release blocker, because if someone thinks the issue might be, then we should get a decision on whether it is or not before the release goes out. Relying on a comment seems far too easy for the release manager to accidentally miss it or forget about it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Wed May 30 15:41:58 2018 From: nad at python.org (Ned Deily) Date: Wed, 30 May 2018 15:41:58 -0400 Subject: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!) In-Reply-To: <7D500DE9-1196-465A-BBC5-89652BC6D3CE@stufft.io> References: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com> <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org> <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org> <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com> <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org> <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io> <7D500DE9-1196-465A-BBC5-89652BC6D3CE@stufft.io> Message-ID: <68538F88-1179-41DE-90D6-59A91CC28EF6@python.org> On May 30, 2018, at 15:09, Donald Stufft wrote: > On May 30, 2018, at 3:03 PM, Larry Hastings wrote: >> Yes, ISTM that the Dev Guide covers this. The section on priority says: >> Triagers may recommend this priority and should add the release manager to the nosy list. >> In other words: if a dev thinks an issue should be a release blocker for version X, they should add the RM to the nosy list and make a comment recommending the issue be escalated to release blocker. I thought it was telling that it doesn't instruct triagers to mark the issue as a release blocker themselves. > > That seems a rather poor way of handling it TBH. A key thing is that an escalation for a decision should itself be a release blocker, because if someone thinks the issue might be, then we should get a decision on whether it is or not before the release goes out. Relying on a comment seems far too easy for the release manager to accidentally miss it or forget about it. Yes. And I think Donald's earlier description of the current process was 100% correct. It is true that, at some level, the current "release blocker" could be broken into two separate states, a "release blocker proposed" and "release blocker accepted". But why? In nearly a dozen years of following the bug tracker and the Python process, I don't recall this ever coming up before. As a practical matter, there is absolutely no ambiguity as the issue history shows who set the priority to "release blocker". Again, it's a near foolproof way (since RM's are not allowed to make a release with a "release blocker" open against that release) to ensure the issue has been evaluated by the RM. And it has worked well for many people for many reasons. And it just doesn't happen very often, i.e. we don't have many release blockers. I think the only reason this came up was because of our policy, enforced by GitHub settings, that merges to "security fix only" branches may only be performed by the release manager, unlike other branches. And in this case, the core developer just wanted to make sure that the release manager saw and acted on the outstanding PR for the security branch. I think that action made perfect sense to me. So, I really really don't think there's a problem today that needs solving and, worse, the suggestions so far add complexity with no benefit at all as far as I can see. May I respectfully suggest that we just drop this discussion and move on, please? -- Ned Deily nad at python.org -- [] From nad at python.org Thu May 31 00:32:14 2018 From: nad at python.org (Ned Deily) Date: Thu, 31 May 2018 00:32:14 -0400 Subject: [python-committers] [RELEASE] Python 3.7.0b5 bonus beta! Message-ID: A 3.7 update: Python 3.7.0b5 is now the final beta preview of Python 3.7, the next feature release of Python. 3.7.0b4 was intended to be the final beta but, due to some unexpected compatibility issues discovered during beta testing of third-party packages, we decided to revert some changes in how Python's 3.7 Abstract Syntax Tree parser deals with docstrings; 3.7.0b5 now behaves like 3.6.x and previous releases (refer to the 3.7.0b5 changelog for more information). **If your code makes use of the ast module, you are strongly encouraged to test (or retest) that code with 3.7.0b5, especially if you previously made changes to work with earlier preview versons of 3.7.0.** As always, please report issues found to bugs.python.org as soon as possible. Please keep in mind that this is a preview release and its use is not recommended for production environments. Attention macOS users: there is now a new installer variant for macOS 10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is expected to become the default version when 3.7.0 releases. Check it out! The next (and final, we hope!) preview release will be the release candidate which is now planned for 2018-06-11, followed by the official release of 3.7.0, now planned for 2018-06-27. You can find Python 3.7.0b5 and more information here: https://www.python.org/downloads/release/python-370b5/ -- Ned Deily nad at python.org -- []