Re: [python-committers] A different way to focus discussions

2018-05-18 Thread Serhiy Storchaka
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 discuss

Re: [python-committers] A different way to focus discussions

2018-05-18 Thread Antoine Pitrou
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 b

Re: [python-committers] Travis & AppVeyor hidden on Github, scroll the invisible region to see them.

2018-05-18 Thread Nathaniel Smith
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

Re: [python-committers] A different way to focus discussions

2018-05-18 Thread Nathaniel Smith
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 exte

Re: [python-committers] A different way to focus discussions

2018-05-18 Thread Nathaniel Smith
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 nuclea

[python-committers] Comments on moving issues to GitHub

2018-05-18 Thread Victor Stinner
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 authent

Re: [python-committers] A different way to focus discussions

2018-05-18 Thread Guido van Rossum
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 th

Re: [python-committers] A different way to focus discussions

2018-05-18 Thread Ivan Levkivskyi
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,

Re: [python-committers] A different way to focus discussions

2018-05-18 Thread Gregory P. Smith
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 creat

Re: [python-committers] A different way to focus discussions

2018-05-18 Thread Guido van Rossum
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

Re: [python-committers] Travis & AppVeyor hidden on Github, scroll the invisible region to see them.

2018-05-18 Thread Gregory P. Smith
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://githu

Re: [python-committers] A different way to focus discussions

2018-05-18 Thread Carol Willing
> 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 PE

Re: [python-committers] A different way to focus discussions

2018-05-18 Thread Ivan Levkivskyi
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 py

[python-committers] A different way to focus discussions

2018-05-18 Thread 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

Re: [python-committers] Bring back Travis & AppVeyor, make VSTS non-blocking

2018-05-18 Thread Terry Reedy
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 -

Re: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

2018-05-18 Thread Serhiy Storchaka
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