2.6.3rc1 is tagged. Martin, Ronald have at it!
Everyone else, please still do not commit anything to the 2.6 tree
without asking first. Only critical brown-bag bug fixes from now
until the final release on Friday.
Begin forwarded message:
> From: barry.warsaw <python-checkins(a)python.org>
> Date: September 29, 2009 6:42:39 PM EDT
> To: python-checkins(a)python.org
> Subject: [Python-checkins] r75152 - python/tags/r263rc1
> Message-Id: <20090929224239.C923AE3B61(a)mail.wooz.org>
>
> Author: barry.warsaw
> Date: Wed Sep 30 00:42:33 2009
> New Revision: 75152
>
> Log:
> Taggint 2.6.3rc1
>
>
> Added:
> python/tags/r263rc1/
> - copied from r75151, /python/branches/release26-maint/
> _______________________________________________
> Python-checkins mailing list
> Python-checkins(a)python.org
> http://mail.python.org/mailman/listinfo/python-checkins
Please, no more commits now on the 2.6 branch until further notice. I
will start building the release in about an hour. Ping me on irc with
any last minute issues.
-Barry
As previously announced, I'm planning on releasing 2.6.3rc1 tonight,
at about 2230 UTC. Right now we have three release blockers, which I'm
reviewing now (and Antoine just said on IRC that he's closing one of
them now).
http://bugs.python.org/issue?@columns=title,id,activity,versions,assignee&@…
Please refrain from committing any changes to 2.6.3 from now until the
release, unless they specifically close one of the blockers, or you
contact me on #python-dev or by email first. I'll be imposing a hard-
freeze on checkins at 2100 UTC today (5pm US/Eastern).
After 2.6.3rc1 is out, please do not commit anything to that branch
without checking with me first. I'll only accept brown-bag removing
patches, and I want to have a stable tree by Thursday so that we can
get Windows and Mac binaries built for Friday's release.
Thanks!
-Barry
I would like to propose we give the commit bit to Doug Hellmann in
order for him to help out with documentation and GHOP style tasks
(he's helped in the past).
You might know him from the "Python Module of the Week" series here:
http://www.doughellmann.com/PyMOTW/
Many of his examples, and doc snippets have landed in our official
documentation. I myself am working on pulling in his multiprocessing
documents for mp's docs. I know Georg sounded positive on this
(correct me if I wrong Georg) - he's a great, great doc writer and I
think he could help out a lot.
jesse
Often the NEWS entry ends up being rewritten from the commit message to be
more user-focussed description of the change...
On Sep 14, 2009 6:33 PM, "Georg Brandl" <g.brandl(a)gmx.net> wrote:
Brett Cannon schrieb:
>> brainstorm: >> >> It'd be nicer if we could generate the file from
another source, >> perhaps ke...
We should just switch to Mercurial :)
I've already hacked up a hg extension to automatically fill the commit
message
with the changes in a NEWS or CHANGELOG file. This works quite well -- you
add the short but nice description to NEWS, do "hg commit", and the editor
pops up where you can either accept the message consisting of only the
changes
in NEWS, or add some more stuff that's not interesting to users.
cheers,
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
_______________________________________________ python-committers mailing
list python-committers@py...
Le lundi 14 septembre 2009 à 12:40 +0200, Georg Brandl a écrit :
> Yes, but still: in many cases they are very similar.
>
> Plus, it's hard to auto-add a NEWS entry from a commit message (because
> you need to determine the right section), while it's easy to pre-fill
> the commit message from a NEWS diff.
This sounds like a better approach indeed.
Antoine.
While looking at the diffs between the 261 release tags and the 26 branch, I
noticed many items in Misc/NEWS appearing in the 2.6.1 or even 2.6 sections.
I moved all of these to 2.6.2, after checking some of them, and found all of the
checked ones be backported after the 2.6.1 release. Is there anything what could
be done to avoid these wrong merges?
I plan to check the items on the 3.0 branch soon.
Matthias
issue6844 wants to stop a warning from being raised when someone
accesses a 'message' attribute on an exception when it is set by the
user (currently any usage of the 'message' attribute raises a
warning). To do this properly is going to require some state flag on
BaseException's struct. But I don't know if that constitutes breaking
the ABI during a micro release or not. I figure no but I wanted to
double-check.
-Brett