all fixed

On Wed, Feb 2, 2011 at 03:04, Sandro Tosi <sandro.t...@gmail.com> wrote:
> On Wed, Jan 26, 2011 at 23:20, brett.cannon <python-check...@python.org> 
> wrote:
>> +The in-development branch is where new functionality and semantic changes
>
> new functionalities (dunno if it's plural in english or not)?
>
>> +occur. Currently this branch is known as the "py3k" branch. The next minor
>> +release of Python will come from this branch (major releases are once a 
>> decade
>> +and so have no specific rules on how they are started). All changes land in 
>> this
>> +branch and then trickle down to other branches.
>> +
>> +Once a Final_ release is made from the in-development branch, a branch is 
>> made
>> +to represent the minor version of Python and it goes into maintenance mode.
>> +Typically a minor version of Python is under development for about 18 
>> months.
>> +
>> +
>> +Maintenance
>> +-----------
>> +The branch currently being maintained for bug fixes.
>> +
>> +The branch under maintenance is the last minor version of Python to be 
>> released
>> +as Final_. This means that the latest release of Python was 3.1.2, then the
>
> if the latest release ?
>
>> +branch representing Python 3.1 is in maintenance mode.
>> +
>> +The only changes allowed to occur in a maintenance branch without debate 
>> are bug
>> +fixes.
>> +Semantic changes **must** be carefully considered as code out in the world 
>> will
>> +have already been developed that will rely on the released semantics. 
>> Changes
>> +related to semantics should be discussed on python-dev before being made.
>> +
>> +A branch stays in maintenance mode as long as a new minor release has not 
>> been
>> +made. For example, this means that Python 2.6 stayed in maintenance mode 
>> until
>> +Python 2.7.0 was released, at which point 2.7 went into maintenance mode and
>> +2.6 went into Security_ mode. As new minor releases occur on a (roughly) 18
>> +month schedule, a branch stays in mainteance mode for the same amount of 
>> time.
>
> s/mainteance/maintenance/
>
>> +
>> +A micro release of a maintenance branch is made about every six months.
>> +Typically when a new minor release is made one more release of the new-old
>> +version of Python is made.
>> +
>> +
>> +Security
>> +--------
>> +A branch less than five years old but no longer in maintenance mode.
>> +
>> +The only changes made to a branch that is being maintained for security
>> +purposes are somewhat obviously those related to security, e.g., privilege
>> +escalation. Crashers and other behaviorial issues are **not** considered a
>
> s/Crashers/Crashes/
> s/behaviorial/behavioral/
>
>> +security risk and thus not backported to a branch being maintained for
>> +security. Any releases made for a branch under security maintenance is
>
> s/releases/release/ ?
> s/for/from/
>
>> +source-only and done only when actual security patches have been applied to 
>> the
>> +branch.
>> +
>> +
>> +Stages
>> +''''''
>> +
>> +Based on what stage the in-development version of Python is in, the
>> +responsibilities of a core developer change in regards to commits to the 
>> VCS.
>> +
>> +
>> +Pre-alpha
>> +---------
>> +This is the stage a branch is in from the last final release until the first
>> +alpha (a1). There are no special restrictions placed on commits beyond those
>> +imposed by the type of branch being worked on (e.g., in-development vs.
>> +maintenance).
>> +
>> +
>> +Alpha
>> +-----
>> +Alphas typically serve as a reminder to core developers that they need to 
>> start
>> +getting in changes that change semantics or add something to Python as such
>> +things should not be added during a Beta_. Otherwise no new restrictions 
>> are in
>> +place while in alpha.
>> +
>> +
>> +Beta
>> +----
>> +A branch in beta means that no new additions to Python are accepted. 
>> Bugfixes
>> +and the like are still fine. Being in beta can be viewed much like being in 
>> RC_
>> +but without the extra overhead of needing commit reviews.
>> +
>> +
>> +.. _RC:
>> +
>> +Release Candidate (RC)
>> +----------------------
>> +A branch preparing for an RC release can only have bugfixes applied that 
>> have
>> +been reviewed by other core developers. That reviewer should make a post to 
>> the
>> +issue related to the change and be mentioned in the commit message.
>> +
>> +You **cannot** skip the peer review during an RC, no matter how small! Even 
>> if
>> +it is a simple copy-and-paste change, **everything** requires peer review 
>> from
>> +a core developer.
>> +
>> +
>> +Final
>> +-----
>> +When a final release is being cut, only the release manager (RM) can make
>> +changes to the branch.
>> diff --git a/index.rst b/index.rst
>> --- a/index.rst
>> +++ b/index.rst
>> @@ -20,6 +20,7 @@
>>    coredev
>>    developers
>>    committing
>> +   devcycle
>>
>>    stdlibchanges
>>    langchanges
>> @@ -64,6 +65,7 @@
>>  * :ref:`coredev`
>>     * :ref:`developers`
>>     * :ref:`committing`
>> +    * :ref:`devcycle`
>>
>>
>>  Proposing changes to Python itself
>>
>> --
>> Repository URL: http://hg.python.org/devguide
>> _______________________________________________
>> Python-checkins mailing list
>> python-check...@python.org
>> http://mail.python.org/mailman/listinfo/python-checkins
>>
>>
>
>
>
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to