On Wed, Jan 26, 2011 at 23:20, brett.cannon <python-checkins(a)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.
> +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
> +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.
> +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.
> +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
> +security risk and thus not backported to a branch being maintained for
> +security. Any releases made for a branch under security maintenance is
> +source-only and done only when actual security patches have been applied to the
> +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.
> +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.
> +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.
> +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.
> +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 @@
> + devcycle
> @@ -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
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
On Thu, Feb 3, 2011 at 7:38 AM, eric.araujo <python-checkins(a)python.org> wrote:
> Author: eric.araujo
> Date: Wed Feb 2 22:38:37 2011
> New Revision: 88324
> Merged revisions 86236,86240,86332,86340,87271,87273,87447 via svnmerge from
> The missing NEWS entries correspond to changes that were made before 3.1.3, but
> I think it’s not usual to edit entries of released versions, so I put them at
> the top.
The only reason it isn't usual is because the change normally goes in
at roughly the same time as the NEWS update, so it is very rare to
have a change in a release without the corresponding NEWS entry. If
NEWS entries get missed for the release, better to add them in the
right place afterwards (it's easy enough to tell which entries were
originally missing by comparing the NEWS file from source control with
the one from the release).
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
There is a bunch of stuff in Misc that probably belongs in the
devguide (under Resources) instead of in svn. Here are the files I
think can be moved (in order of how strongly I think they should be
Now before anyone yells "that is inconvenient", don't forget that all
core developers can check out and edit the devguide, and that almost
all of the files listed (SpecialBuilds.txt is the exception) are
typically edited and viewed on their own.
Anyway, if there is a file listed here you don't think should move out
of py3k and into the devguide, speak up.
This is my first stab at contributing to this list. I'm writing to lobby for bug #8797's fix to be removed and for my fix to put in in its place. I'm probably doing this wrong, so please bear with me. I will embrace whatever scathing criticism I get.
The ticket covers all the details (http://bugs.python.org/issue8797#) but I'll try to summarize here:
In 2.6.5, urllib2 had a small regression that caused HTTP 401 errors to trigger an infinite recursion when the request handler had HTTP Auth credentials that the server was rejecting.
Previously, urllib2 avoided this loop by checking the previous request's headers to see if it had already tried the credentials it was about to try. If it had, it would re-raise the exception instead of trying again.
The current fix adds a "max retries" concept to urllib2's handling of HTTP 401 errors so that the code will only retry a certain number of times.
To me, the original logic of only trying once for each set of credentials was sound, and it looks like the only reason this stopped working was that in 2.6.5 the auth header wasn't being stored in the same place as the code was expecting to find it.
I think it makes sense to revisit this issue and swap out the existing fix for my fix because it's tidier and doesn't introduce this new "max retries" functionality.
Please let me know what you think.
> --- python/branches/release31-maint/Lib/configparser.py (original)
> +++ python/branches/release31-maint/Lib/configparser.py Wed Feb 2 22:35:48 2011
> @@ -88,7 +88,7 @@
> - from collections import OrderedDict as _default_dict
> + from collections import Mapping, OrderedDict as _default_dict
> except ImportError:
> # fallback for setup.py which hasn't yet built _collections
> _default_dict = dict
Buildbots can’t compile after that change, because Mapping is not found.
I suggest aliasing Mapping to dict in the except block (untested).
In an attempt to record the xml exchange in an xmlrpclib.ServerProxy
connection, I set its verbose flag to 1.
This is the whole premise, and the rest of this message contains a bug
report, and general complaints about the API.
ServerProxy, or to be a bit more specific, the Transport class (which does
all the actual printing), provides very little control over where the output
By very little, I mean it only outputs to stdout, which is limiting in a
server environment where many a prints occur.
That, however, turned out to be the least of my worries: xmlrpclib depends
on httplib.HTTP to print the outgoing data, but prints its own incoming
and they tend to collide, in what I permit myself to call a "race
condition", though it's mostly just simple lack of management of a shared
The resulting output is mostly well-formed, with the occasional nonsense
produced by an interjection of one string to the middle of the other.
Also, there's the nasty business of Transport.request accepting a 'verbose'
param, and then setting it as an instance attribute and using *that*, for no
apparent reason except to cause yet another potential race condition.
I suggest that httplib.HTTP's verbosity will be controlled by a separate
flag, if controlled at all.
The outgoing communication can easily be printed by transport, allowing for
better control of synchrony.
Also, ServerProxy should accept an optional output file (=a class with
write,writelines methods), which will be the target of all prints.
Would Python be interested in such a patch?
On Tue, Jan 18, 2011 at 2:35 PM, Antoine Pitrou <solipsis(a)pitrou.net> wrote:
> On Tue, 18 Jan 2011 07:14:51 +0100
> Ezio Melotti <ezio.melotti(a)gmail.com> wrote:
>> > +
>> > +Committing Patches
>> > +==================
>> > +
>> > + svnmerge.py merge -r 42
>> > +
>> > +This will try to apply the patch to the current patch and generate a
>> > commit
> Do we want to spend so much time explaining how to use SVN for core
> developers while we're supposed to switch to Mercurial Real Soon Now?
> (current core devs already know how to use it, and we don't get many
> new ones every month)
How about patches sent by users who track and fix bugs directly in
codebase of their Python installation?
Making and testing a patch from Python checkout requires compiling
Python, which is not possible for Windows users. We should add less
hardcore instructions how to use bundled diff.py for creating simple
patches like docstring, comment fixes or generating new testcases.
This will greatly reduce the barrier for starting with development.
On 2011/02/02 07:18:33, Martin v. Löwis wrote:
> Ah. That shouldn't be done. If anything is to be done, the builtin
msilib can be
> considered, instead. Given the choice of using either ctypes or an
> package, I prefer the external package.
It is a surprise to find builtin msilib. Why isn't it used? Is an
incremental transition to builtin possible?