[issue23077] PEP 1: Allow Provisional status for PEPs

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Closing as third party since this moved to the PEP repository.

--
resolution:  -> third party
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23077] PEP 1: Allow Provisional status for PEPs

[Nick Coghlan]

Nick Coghlan  added the comment:

I'll also note that I made my comments above about writing a new PEP prior to 
the migration to GitHub and the availability of a PR-based workflow for 
reviewing PEP changes.

So consider the PR Cheryl linked and the post at 
https://mail.python.org/pipermail/python-dev/2018-February/152205.html the 
replacement for that PEP suggestion :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23077] PEP 1: Allow Provisional status for PEPs

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Pull request:
https://github.com/python/peps/pull/577

--
nosy: +csabella

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23077] PEP 1: Allow Provisional status for PEPs

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Dec 31, 2014, at 01:54 AM, Nick Coghlan wrote:

As we've started working through the post-release PEP 440 changes, I think
this is definitely worthy of a separate PEP.

I'm open to discussion and ideas, but I want to caution against spreading
information about the PEP (and more largely, enhancing Python) process over
too many documents.   PEP 1 and the process has worked well I think because
it's relatively easy to find information on the process in a concise format.
I also don't think we necessarily need to cross-and-dot every I-and-T.
Flexibility can be a good thing too.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23077
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23077] PEP 1: Allow Provisional status for PEPs

[Nick Coghlan]

Nick Coghlan added the comment:

The new PEP wouldn't be a permanent one - it would be describing the proposed 
changes to PEP 1, and the rationale for them.

It would be for my own benefit as much as anyone's - if I can't explain the 
proposed change and its intended benefits clearly in PEP form, its probably a 
bad idea :)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23077
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23077] PEP 1: Allow Provisional status for PEPs

[Nick Coghlan]

Nick Coghlan added the comment:

As we've started working through the post-release PEP 440 changes, I think this 
is definitely worthy of a separate PEP. I'll take the opportunity to pitch some 
other changes as well, like separating out the interoperability standards from 
the informational PEPs like the CPython release process guide, and add new 
metadata headers to indicate when the reference implementation of a standard is 
provided by a project other than CPython.

We may decide the extra complexity isn't worth it, but after wrangling PEP 440 
through to completion under the delegation of authority to distutils-sig, I'd 
at least like to have the discussion about what we think represents a 
necessary, but sufficient level of process change.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23077
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23077] PEP 1: Allow Provisional status for PEPs

[Nick Coghlan]

New submission from Nick Coghlan:

As per python-dev discussion [1], filing this as the home for a proposed update 
to PEP 1 that allows Standards Track PEPs to be granted Provisional status 
before moving on to Accepted/Final.

The new status will be for PEPs where we want to release an initial reference 
implementation (whether in CPython under PEP 411 or through the PyPA toolchain) 
before locking down the exact details of the API specification.

[1] https://mail.python.org/pipermail/python-dev/2014-December/137622.html

--
assignee: ncoghlan
messages: 232842
nosy: Jeremy.Hylton, barry, goodger, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: PEP 1: Allow Provisional status for PEPs
type: enhancement

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23077
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com