Re: [python-committers] default hg.python.org/cpython is now 3.5

2014-03-17 Thread Victor Stinner
Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2 only
accept security fixes, right?

Victor
Le 17 mars 2014 07:48, "Larry Hastings"  a écrit :

>
>
> The "3.4" branch is now checked in.  It contains all the 3.4 releases
> since 3.4.0rc1.  Its current state is effectively 3.4.1.
>
> The "default" branch is now 3.5.
>
> Cry havoc, and let slip the dogs of war,
>
>
> */arry*
>
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
>
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


[python-committers] 3.4 buildbots??

2014-03-17 Thread Jesus Cea
Do I need to do anything to create the 3.4 branch in the buildbots?.

-- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
[email protected] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:[email protected]  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz



signature.asc
Description: OpenPGP digital signature
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] default hg.python.org/cpython is now 3.5

2014-03-17 Thread Brett Cannon
On Mon, Mar 17, 2014 at 4:51 AM, Victor Stinner wrote:

> Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2 only
> accept security fixes, right?
>

Typically we do one last release before shutting the last bugfix branch
down, but that's Georg's call since 3.3.5 was released so recently.

-Brett


> Victor
> Le 17 mars 2014 07:48, "Larry Hastings"  a écrit :
>
>>
>>
>> The "3.4" branch is now checked in.  It contains all the 3.4 releases
>> since 3.4.0rc1.  Its current state is effectively 3.4.1.
>>
>> The "default" branch is now 3.5.
>>
>> Cry havoc, and let slip the dogs of war,
>>
>>
>> */arry*
>>
>> ___
>> python-committers mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-committers
>>
>>
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
>
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] 3.4 buildbots??

2014-03-17 Thread Martin v. Löwis
Am 17.03.14 14:52, schrieb Jesus Cea:
> Do I need to do anything to create the 3.4 branch in the buildbots?.

As a slave operator, you don't need to do anything. As the master
operator, you would have to edit the configuration file to add the
branch.

However, I would advise against doing so now, and delay the addition
of the 3.4 branch until 3.3 is retired from bug fixing, and then
repurpose all 3.3 configuration for 3.4. Otherwise, some slaves might
run out of disk space.

As the master operator, it would also be nice to slave operators if
the 3.3 build directories get cleaned up, by targeting them to

http://hg.python.org/buildbot/empty/

once, and triggering a rebuild.

Regards,
Martin

___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] 3.4 buildbots??

2014-03-17 Thread Zachary Ware
On Mon, Mar 17, 2014 at 9:16 AM, "Martin v. Löwis"  wrote:
> Am 17.03.14 14:52, schrieb Jesus Cea:
>> Do I need to do anything to create the 3.4 branch in the buildbots?.
>
> As a slave operator, you don't need to do anything. As the master
> operator, you would have to edit the configuration file to add the
> branch.
>
> However, I would advise against doing so now, and delay the addition
> of the 3.4 branch until 3.3 is retired from bug fixing, and then
> repurpose all 3.3 configuration for 3.4. Otherwise, some slaves might
> run out of disk space.

Since we still have a 3.2 configuration (for which most of the UNIX
bots are broken), perhaps we should repurpose that configuration
instead of 3.3.

> As the master operator, it would also be nice to slave operators if
> the 3.3 build directories get cleaned up, by targeting them to
>
> http://hg.python.org/buildbot/empty/
>
> once, and triggering a rebuild.

It would also be good to clear out the external library sources for
the Windows buildbots to allow a fresh start there.

--
Zach
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] default hg.python.org/cpython is now 3.5

2014-03-17 Thread Benjamin Peterson


On Mon, Mar 17, 2014, at 7:10, Brett Cannon wrote:
> On Mon, Mar 17, 2014 at 4:51 AM, Victor Stinner
> wrote:
> 
> > Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2 only
> > accept security fixes, right?
> >
> 
> Typically we do one last release before shutting the last bugfix branch
> down, but that's Georg's call since 3.3.5 was released so recently.

Given that, I propose 3.3 goes into security fix mode immediately.
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] default hg.python.org/cpython is now 3.5

2014-03-17 Thread Jesus Cea
On 17/03/14 09:51, Victor Stinner wrote:
> Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2
> only accept security fixes, right?

Tradition says that until release *.1 is published. That is, 3.4.1 in
this case.

But release manager will tell.

-- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
[email protected] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:[email protected]  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz



signature.asc
Description: OpenPGP digital signature
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] 3.4 buildbots??

2014-03-17 Thread Antoine Pitrou
On lun., 2014-03-17 at 09:37 -0500, Zachary Ware wrote:
> On Mon, Mar 17, 2014 at 9:16 AM, "Martin v. Löwis"  wrote:
> > Am 17.03.14 14:52, schrieb Jesus Cea:
> >> Do I need to do anything to create the 3.4 branch in the buildbots?.
> >
> > As a slave operator, you don't need to do anything. As the master
> > operator, you would have to edit the configuration file to add the
> > branch.
> >
> > However, I would advise against doing so now, and delay the addition
> > of the 3.4 branch until 3.3 is retired from bug fixing, and then
> > repurpose all 3.3 configuration for 3.4. Otherwise, some slaves might
> > run out of disk space.
> 
> Since we still have a 3.2 configuration (for which most of the UNIX
> bots are broken), perhaps we should repurpose that configuration
> instead of 3.3.

That would be Georg's call, since he's the RM for both branches (AFAIR).

Regards

Antoine.


___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] 3.4 buildbots??

2014-03-17 Thread Jesus Cea
On 17/03/14 15:16, "Martin v. Löwis" wrote:
> However, I would advise against doing so now, and delay the addition
> of the 3.4 branch until 3.3 is retired from bug fixing, and then
> repurpose all 3.3 configuration for 3.4. Otherwise, some slaves might
> run out of disk space.

Are you actually talking about 3.2?. I am surprised that you propose to
delay 3.4 buildbots now that it is the "current" release. Doesn't make
sense to me.

Why not drop 3.2 and do only 2.7, 3.3, 3.4 and default (future 3.5)?.

-- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
[email protected] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:[email protected]  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz



signature.asc
Description: OpenPGP digital signature
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] default hg.python.org/cpython is now 3.5

2014-03-17 Thread Martin v. Löwis
Am 17.03.14 16:18, schrieb Benjamin Peterson:
> 
> 
> On Mon, Mar 17, 2014, at 7:10, Brett Cannon wrote:
>> On Mon, Mar 17, 2014 at 4:51 AM, Victor Stinner
>> wrote:
>>
>>> Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2 only
>>> accept security fixes, right?
>>>
>>
>> Typically we do one last release before shutting the last bugfix branch
>> down, but that's Georg's call since 3.3.5 was released so recently.
> 
> Given that, I propose 3.3 goes into security fix mode immediately.

+1

Martin


___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] [Python-Dev] [RELEASED] Python 3.4.0

2014-03-17 Thread Giampaolo Rodola'
The what's new looks truly amazing, with pathlib and asyncio being my
favourite additions.
Thanks for all the hard work.


On Mon, Mar 17, 2014 at 5:57 PM, Ryan Gonzalez  wrote:

> YES!!! +1 to the authors of the statistics and pathlib modules.
>
>
> On Mon, Mar 17, 2014 at 1:29 AM, Larry Hastings wrote:
>
>>
>> On behalf of the Python development team, I'm thrilled to announce
>> the official release of Python 3.4.
>>
>>
>> Python 3.4 includes a range of improvements of the 3.x series, including
>> hundreds of small improvements and bug fixes.  Major new features and
>> changes in the 3.4 release series include:
>>
>> * PEP 428, a "pathlib" module providing object-oriented filesystem paths
>> * PEP 435, a standardized "enum" module
>> * PEP 436, a build enhancement that will help generate introspection
>>information for builtins
>> * PEP 442, improved semantics for object finalization
>> * PEP 443, adding single-dispatch generic functions to the standard
>> library
>> * PEP 445, a new C API for implementing custom memory allocators
>> * PEP 446, changing file descriptors to not be inherited by default
>>in subprocesses
>> * PEP 450, a new "statistics" module
>> * PEP 451, standardizing module metadata for Python's module import system
>> * PEP 453, a bundled installer for the *pip* package manager
>> * PEP 454, a new "tracemalloc" module for tracing Python memory
>> allocations
>> * PEP 456, a new hash algorithm for Python strings and binary data
>> * PEP 3154, a new and improved protocol for pickled objects
>> * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O
>>
>>
>> To download Python 3.4.0 visit:
>>
>> http://www.python.org/download/releases/3.4.0/
>>
>>
>> This is a production release.  Please report any issues you notice to:
>>
>>  http://bugs.python.org/
>>
>>
>> Enjoy!
>>
>>
>> --
>> Larry Hastings, Release Manager
>> larry at hastings.org
>> (on behalf of the entire python-dev team and 3.4's contributors)
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
>> rymg19%40gmail.com
>>
>
>
>
> --
> Ryan
> If anybody ever asks me why I prefer C++ to C, my answer will be simple:
> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
> nul-terminated."
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>


-- 
Giampaolo - http://grodola.blogspot.com
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] default hg.python.org/cpython is now 3.5

2014-03-17 Thread Georg Brandl
Am 17.03.2014 17:37, schrieb "Martin v. Löwis":
> Am 17.03.14 16:18, schrieb Benjamin Peterson:
>> 
>> 
>> On Mon, Mar 17, 2014, at 7:10, Brett Cannon wrote:
>>> On Mon, Mar 17, 2014 at 4:51 AM, Victor Stinner
>>> wrote:
>>>
 Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2 only
 accept security fixes, right?

>>>
>>> Typically we do one last release before shutting the last bugfix branch
>>> down, but that's Georg's call since 3.3.5 was released so recently.
>> 
>> Given that, I propose 3.3 goes into security fix mode immediately.
> 
> +1

I agree.  I would have released 3.3.5 after 3.4.0, but since 3.3.5 came along
*and* took a second rc, it fills the function nicely.

I will make an exception if a regression in 3.3.5 is discovered soon-ish.

Georg

___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] 3.4 buildbots??

2014-03-17 Thread Martin v. Löwis
Am 17.03.14 16:58, schrieb Jesus Cea:
> On 17/03/14 15:16, "Martin v. Löwis" wrote:
>> However, I would advise against doing so now, and delay the addition
>> of the 3.4 branch until 3.3 is retired from bug fixing, and then
>> repurpose all 3.3 configuration for 3.4. Otherwise, some slaves might
>> run out of disk space.
> 
> Are you actually talking about 3.2?. I am surprised that you propose to
> delay 3.4 buildbots now that it is the "current" release. Doesn't make
> sense to me.

No - the "current" branch is 3.5. The rationale for not creating
buildbots for them right away is that 3.4 just had a release, and
the next release might be a few month ahead, so enabling buildbots
four weeks from now might still be early enough.

> Why not drop 3.2 and do only 2.7, 3.3, 3.4 and default (future 3.5)?.

I was actually unaware that there is a 3.2 configuration still;
repurposing that is then fine with me. However, it might be a little
bit more complicated, since the 3.2 configuration is not listed in

https://www.python.org/dev/buildbot/

so you'll have to create a bunch of proxy, alias, redirect and whatnot
configurations if you want to expose a fourth branch.

Regards,
Martin

___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


[python-committers] 3.3 branch is now in security fix mode

2014-03-17 Thread Georg Brandl
Hi all,

since 3.3.5 and 3.4.0 practically coincided, it is a good point to end the
bugfix maintenance of the 3.3 branch.

Please only commit security-related fixes to 3.3 from now -- like for 3.2 --
and as always, please set tracker issues that relate to security fixes to
"release blocker" priority.

Georg

___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] default hg.python.org/cpython is now 3.5

2014-03-17 Thread Terry Reedy

On 3/17/2014 11:18 AM, Benjamin Peterson wrote:



On Mon, Mar 17, 2014, at 7:10, Brett Cannon wrote:

On Mon, Mar 17, 2014 at 4:51 AM, Victor Stinner
wrote:


Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2 only
accept security fixes, right?



Typically we do one last release before shutting the last bugfix branch
down, but that's Georg's call since 3.3.5 was released so recently.


Given that, I propose 3.3 goes into security fix mode immediately.


Traditionally, the final maintenance release has been either 
simultaneous or a week after the next version. Having 3 active 3.x 
branches on top of 2.x is a burden. I also think a week before is fine.


Terry

___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] default hg.python.org/cpython is now 3.5

2014-03-17 Thread Terry Reedy

On 3/17/2014 11:42 AM, Jesus Cea wrote:

On 17/03/14 09:51, Victor Stinner wrote:

Until when should we fix bugs in the branch 3.3? Branches 3.1 and 3.2
only accept security fixes, right?


Tradition says that until release *.1 is published. That is, 3.4.1 in
this case.


According to my memory, bug fixing traditionally stopped with the next 
x.y.0 release (but which was not called .0)



But release manager will tell.


Having multiple branches under maintenance severely affect all committers.

Terry


___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] default hg.python.org/cpython is now 3.5

2014-03-17 Thread Victor Stinner
Hi,

I modified the Misc/NEWS file:

* I moved 3.3 sections to Misc/HISTORY: items were already present,
but the format in Misc/NEWS was improved (changeset 6ba468d4fa96)
* I removed 3.4.1 section: changes of 3.4 after 3.4.0 must already be
present in the 3.4 branch (changeset cb161cd94e6e)

Is that correct?

Victor

2014-03-17 7:38 GMT+01:00 Larry Hastings :
>
>
> The "3.4" branch is now checked in.  It contains all the 3.4 releases since
> 3.4.0rc1.  Its current state is effectively 3.4.1.
>
> The "default" branch is now 3.5.
>
> Cry havoc, and let slip the dogs of war,
>
>
> /arry
>
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] default hg.python.org/cpython is now 3.5

2014-03-17 Thread Nick Coghlan
On 18 Mar 2014 07:37, "Victor Stinner"  wrote:
>
> Hi,
>
> I modified the Misc/NEWS file:
>
> * I moved 3.3 sections to Misc/HISTORY: items were already present,
> but the format in Misc/NEWS was improved (changeset 6ba468d4fa96)
> * I removed 3.4.1 section: changes of 3.4 after 3.4.0 must already be
> present in the 3.4 branch (changeset cb161cd94e6e)
>
> Is that correct?

Not everything was cherry picked, so we'll need to review that to move the
3.4.1 fixes back to the appropriate section.

Cheers,
Nick.

>
> Victor
>
> 2014-03-17 7:38 GMT+01:00 Larry Hastings :
> >
> >
> > The "3.4" branch is now checked in.  It contains all the 3.4 releases
since
> > 3.4.0rc1.  Its current state is effectively 3.4.1.
> >
> > The "default" branch is now 3.5.
> >
> > Cry havoc, and let slip the dogs of war,
> >
> >
> > /arry
> >
> > ___
> > python-committers mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/python-committers
> >
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] default hg.python.org/cpython is now 3.5

2014-03-17 Thread Larry Hastings

On 03/17/2014 04:23 PM, Nick Coghlan wrote:



On 18 Mar 2014 07:37, "Victor Stinner" > wrote:

>
> Hi,
>
> I modified the Misc/NEWS file:
>
> * I moved 3.3 sections to Misc/HISTORY: items were already present,
> but the format in Misc/NEWS was improved (changeset 6ba468d4fa96)
> * I removed 3.4.1 section: changes of 3.4 after 3.4.0 must already be
> present in the 3.4 branch (changeset cb161cd94e6e)
>
> Is that correct?

Not everything was cherry picked, so we'll need to review that to move 
the 3.4.1 fixes back to the appropriate section.




I merged "default" into "3.4" (3a3a83195159), so every change that was 
in "default" last night will automatically go into 3.4.1.  Stuff that 
got cherry-picked back for 3.4.0 should already be in their correct 
sections.


I worked pretty hard to get that right, so while I'd be interested to 
hear if I got it wrong, my assumption (my hope) for now is that 
Misc/NEWS is basically correct in both "3.4" and "default".



//arry/
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers


Re: [python-committers] default hg.python.org/cpython is now 3.5

2014-03-17 Thread Georg Brandl
Am 17.03.2014 22:36, schrieb Victor Stinner:
> Hi,
> 
> I modified the Misc/NEWS file:
> 
> * I moved 3.3 sections to Misc/HISTORY: items were already present,
> but the format in Misc/NEWS was improved (changeset 6ba468d4fa96)
> * I removed 3.4.1 section: changes of 3.4 after 3.4.0 must already be
> present in the 3.4 branch (changeset cb161cd94e6e)
> 
> Is that correct?

The changes not merged in 3.4.0 will all be in 3.5.0; please reinstate the
NEWS entries under the 3.5 heading.

Georg

___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers