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

[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
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).
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[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 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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[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 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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[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 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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Comments on moving issues to GitHub

[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 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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[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 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
>
>
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[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, 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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[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 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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[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 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@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)
___
python-committers mailing list

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

[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://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@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@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[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 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@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@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[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
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@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@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] A different way to focus discussions

[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.

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@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[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 - 
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


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/