[Python-Dev] Two small PEP ideas

[Guido van Rossum]

On Tue, Apr 27, 2010 at 10:46 AM, Barry Warsaw <barry at python.org> wrote:
> I have two somewhat unrelated thoughts about PEPs.
>
> * Accepted: header
>
> When PEP 3147 was accepted, I had a few folks ask that this be recorded in the
> PEP by including a link to the BDFL pronouncement email.  I realized that
> there's no formal way to express this in a PEP, and many PEPs in fact don't
> record more than the fact that it was accepted.  I'd like to propose
> officially adding an Accepted: header which should include a URL to the email
> or other web resource where the PEP is accepted.  I've come as close as
> possible to this (without modifying the supporting scripts or PEP 1) in PEP
> 3147:
>
>    http://www.python.org/dev/peps/pep-3147/
>
> I'd be willing to update things if there are no objections.

I'd rather not build a single point of failure into the process.
Instead of insisting on BDFL pronouncement, the community should
switch do something like "last call for objections." There should also
be a timeline so that unproductive discussion can't be dragged on
forever.

> * EOL schedule for older releases.
>
> We have semi-formal policies for the lifetimes of Python releases, though I'm
> not sure this policy is written down in any of the existing informational
> PEPs.  However, we have release schedule PEPs going back to Python 1.6.  It
> seems reasonable to me that we include end-of-life information in those PEPs.
> For example, we could state that Python 2.4 is no longer even being maintained
> for security, and we could state the projected date that Python 2.6 will go
> into security-only maintenance mode.
>
> I would not mandate that we go back and update all previous PEPs for either of
> these ideas.  We'd adopt them moving forward and allow anyone who's motivated
> to backfill information opportunistically.

SGTM.

-- 
--Guido van Rossum (python.org/~guido)