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. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20110119/89695497/attachment.pgp>
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