On Thu, Jan 20, 2011 at 4:40 AM, Barry Warsaw <barry at python.org> wrote: > On Jan 19, 2011, at 12:16 AM, Nick Coghlan wrote: > >>For the release schedule PEPs it means "done and dusted" (similar to >>the meaning for ordinary PEPs). For the API standardisation PEPs (like >>WSGI) it instead means the spec has been locked down and any changes >>will require a new PEP. This caused a problem for the PEP 0 generator, >>since the former kind of PEP should be moved to the new historical >>section, while the latter kind should remain up top. >> >>Would anyone object if I switched all the API definition PEPs to the >>"Active" state? PEP 1 indicates that is the appropriate state for >>reference PEPs that are never truly "finished" (in the sense of code >>being implemented and committed to the source control system). > > Perhaps we need a new type for API PEPs instead? > > Type: API > Type: Consensus > > ? > > If not, then I'd rather come up with a different status to describe an API PEP > that has been locked down. Re-using Active doesn't seem right to me. Oh, I like "Consensus". I was going to suggest a new state, but I couldn't think of any names I liked. Hmm, guess I'll add "propose a revision to PEP 1" to the to-do list... Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4