From larry at hastings.org  Sun Jan  5 22:20:50 2014
From: larry at hastings.org (Larry Hastings)
Date: Sun, 05 Jan 2014 13:20:50 -0800
Subject: [python-committers] [RELEASED] Python 3.4.0b2
Message-ID: <52C9CCB2.7080703@hastings.org>


On behalf of the Python development team, I'm pleased to announce
the second beta release of Python 3.4.

This is a preview release, and its use is not recommended for
production settings.

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

Python 3.4 is now in "feature freeze", meaning that no new features will be
added.  The final release is projected for late February 2014.


To download Python 3.4.0b2 visit:

     http://www.python.org/download/releases/3.4.0/


Please consider trying Python 3.4.0b2 with your code and reporting any
new 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)

From victor.stinner at gmail.com  Mon Jan  6 11:35:16 2014
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 6 Jan 2014 11:35:16 +0100
Subject: [python-committers] PyCon Language Summit: Wednesday 9th April
In-Reply-To: <C533EC9B-5207-44C7-9A35-81E35639A963@voidspace.org.uk>
References: <C533EC9B-5207-44C7-9A35-81E35639A963@voidspace.org.uk>
Message-ID: <CAMpsgwbmx=9iVxhnbAOso3F7z3X=5eOY37Z1EckO08sRb-P8FA@mail.gmail.com>

Hi,

2013/12/4 Michael Foord <michael at voidspace.org.uk>:
> As with previous years we will be having a Language Summit at PyCon North America, in Montreal. The summit will be on Wednesday 9th April and running from approximately 10am to 4pm.

My talk "Track memory leaks in Python" was accepted, I will be present
at Montreal for Pycon US \o/

For the summit, I think that we must discuss the adoption of Python 3
and try to fix remaining issues to ease porting applications from
Python 2 to Python 3. Mercurial and Twisted are not ported yet, and
some developers consider Python 3 as a mistake. You must try to
understand why and fix remaining issues.

One concrete point is the "support .format for bytes" which was
requested by Mercurial ("for Mercurial this is the single biggest
impediment to even getting our testrunner working, much less starting
the porting process.") and Twisted ("Honestly, what Twisted is mostly
after is a way to write code that works both with Python 2 and Python
3.")
http://bugs.python.org/issue3982

A PEP was requested for this issue, I'm interested to help to write it
and implement it in Python 3.5.

A Python 2.8 version was also proposed to reduce differences between
Python 2 and 3, and so ease porting applications to Python 3. Related
discussion:

"About Python 3"
http://alexgaynor.net/2013/dec/30/about-python-3/

"Debating a "transitional" Python 2.8"
http://lwn.net/Articles/578532/
Free link if you are not subscribed:
http://lwn.net/SubscriberLink/578532/8002e0bc4289a23d/

This mailing list is not the right place to discuss all these points,
I propose to discuss them during the Language Summit. If you would
like to discuss these points right now, please open a discussion in
python-dev or python-ideas.

Victor

From victor.stinner at gmail.com  Mon Jan  6 11:37:09 2014
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 6 Jan 2014 11:37:09 +0100
Subject: [python-committers] PyCon Language Summit: Wednesday 9th April
In-Reply-To: <CAMpsgwbmx=9iVxhnbAOso3F7z3X=5eOY37Z1EckO08sRb-P8FA@mail.gmail.com>
References: <C533EC9B-5207-44C7-9A35-81E35639A963@voidspace.org.uk>
 <CAMpsgwbmx=9iVxhnbAOso3F7z3X=5eOY37Z1EckO08sRb-P8FA@mail.gmail.com>
Message-ID: <CAMpsgwZ0DnpxiTUij-ZP_dgsTB=kCO0aLE-smsWWU6UxjFrdpA@mail.gmail.com>

2014/1/6 Victor Stinner <victor.stinner at gmail.com>:
> You must try to understand why and fix remaining issues.

Oops, I don't understand why, but sometimes I write "you" instead of "we".

*We* must try to understand why and fix remaining issues.

Victor

From solipsis at pitrou.net  Mon Jan  6 16:22:23 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 06 Jan 2014 16:22:23 +0100
Subject: [python-committers] PyCon Language Summit: Wednesday 9th April
In-Reply-To: <CAMpsgwZ0DnpxiTUij-ZP_dgsTB=kCO0aLE-smsWWU6UxjFrdpA@mail.gmail.com>
References: <C533EC9B-5207-44C7-9A35-81E35639A963@voidspace.org.uk>
 <CAMpsgwbmx=9iVxhnbAOso3F7z3X=5eOY37Z1EckO08sRb-P8FA@mail.gmail.com>
 <CAMpsgwZ0DnpxiTUij-ZP_dgsTB=kCO0aLE-smsWWU6UxjFrdpA@mail.gmail.com>
Message-ID: <1389021743.2265.0.camel@fsol>

On lun., 2014-01-06 at 11:37 +0100, Victor Stinner wrote:
> 2014/1/6 Victor Stinner <victor.stinner at gmail.com>:
> > You must try to understand why and fix remaining issues.
> 
> Oops, I don't understand why, but sometimes I write "you" instead of "we".
> 
> *We* must try to understand why and fix remaining issues.

Certainly a keyboard problem :-)

Regards

Antoine.



From larry at hastings.org  Mon Jan  6 16:25:37 2014
From: larry at hastings.org (Larry Hastings)
Date: Mon, 06 Jan 2014 07:25:37 -0800
Subject: [python-committers] 3.4.0b2 release commits merged back into trunk,
 trunk is open for business again EOM
Message-ID: <52CACAF1.80802@hastings.org>



//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140106/7b794d6b/attachment.html>

From larry at hastings.org  Mon Jan  6 22:34:26 2014
From: larry at hastings.org (Larry Hastings)
Date: Mon, 06 Jan 2014 13:34:26 -0800
Subject: [python-committers] Adding a (small) feature to 3.4 for Argument
 Clinic: inspect.Signature supporting simple named constants for default
 values
Message-ID: <52CB2162.2090506@hastings.org>


Serhiy Storchaka ran into a ticklish problem with Argument Clinic and 
inspect.Signature information for builtins.

Consider pattern_match() in Modules/_sre.c.  This implements the match 
method on a pattern object; in other words, re.compile().match().  The 
third parameter, endpos, defaults to PY_SSIZE_T_MAX in C.  What should 
inspect.Signature() report as the default value for endpos?  And how 
should it get that value?

Before you answer, consider how inspect.Signature works for builtins.  
Argument Clinic hides a signature for the function as the first line of 
the docstring; the initialization of the code object strips that off and 
puts it in a separate member called __text_signature__.  
inspect.Signature pulls that out string and passes it in to ast.parse, 
then walks the tree it gets back, pulls out the arguments and their 
default values and goes on from there.

We can't turn PY_SSIZE_T_MAX into an integer at Argument Clinic 
preprocessing time, because this could be done on a completely different 
architecture than the computer where Python is running. We can't stuff 
it in at compile time because the macro could devolve into an arbitrary 
expression (with | or + or something) so while that might work here 
that's not a general solution.  We can't do it at runtime becuase the 
docstring is a static string.

The best solution seems to be: allow simple symbolic constants as 
default values.  For example, for endpos we'd use sys.maxsize.  The code 
in inspect.Signature would have to support getting an Attribute node, 
and look up the first field ("sys" in this case) in sys.modules.  You 
could then specify PY_SSIZE_T_MAX as the default for generated C code, 
and life would be a dream.

I've posted a prototype patch on the tracker:

    http://bugs.python.org/issue20144

It need tests and such but I think the basic technology is fine.


The thing is, I feel like this is borderline between bug fix and new 
feature.  But without adding this, we would make a lot of the Argument 
Clinic conversions pretty messy.  So I want to check it in.  I just 
don't want to piss everybody off in the process.

Can you guys live with this?



/arry

p.s.

For what it's worth, the documentation for match() dodges this problem 
by outright lying.  It claims that the prototype for the function is:

     match(string[, pos[, endpos]])

which is a lie.  pattern_match() parses its arguments by calling 
PyArg_ParseTupleAndKeywords() with a format string of "O|nn".  Which 
means, for example, you could call:

     match("abc", endpos=5)

The documentation suggests this is invalid but it works fine.  So my 
feeling is, this is a legitimate problem, and those who came before me 
swept it under the rug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140106/bf9706ce/attachment.html>

From mal at egenix.com  Mon Jan  6 23:10:54 2014
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 06 Jan 2014 23:10:54 +0100
Subject: [python-committers] Adding a (small) feature to 3.4 for
 Argument Clinic: inspect.Signature supporting simple named constants for
 default values
In-Reply-To: <52CB2162.2090506@hastings.org>
References: <52CB2162.2090506@hastings.org>
Message-ID: <52CB29EE.1010800@egenix.com>

On 06.01.2014 22:34, Larry Hastings wrote:
> 
> p.s.
> 
> For what it's worth, the documentation for match() dodges this problem by outright lying.  It claims
> that the prototype for the function is:
> 
>     match(string[, pos[, endpos]])
> 
> which is a lie.  pattern_match() parses its arguments by calling PyArg_ParseTupleAndKeywords() with
> a format string of "O|nn".  Which means, for example, you could call:
> 
>     match("abc", endpos=5)
> 
> The documentation suggests this is invalid but it works fine.  So my feeling is, this is a
> legitimate problem, and those who came before me swept it under the rug.

Looks like a documentation bug to me. Several functions were changed
to be keyword aware some years ago and the docs you quoted still list
the old positional format.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 06 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

From barry at python.org  Mon Jan  6 23:21:14 2014
From: barry at python.org (Barry Warsaw)
Date: Mon, 6 Jan 2014 17:21:14 -0500
Subject: [python-committers] Adding a (small) feature to 3.4 for
 Argument Clinic: inspect.Signature supporting simple named constants for
 default values
In-Reply-To: <52CB2162.2090506@hastings.org>
References: <52CB2162.2090506@hastings.org>
Message-ID: <20140106172114.493d4ce7@anarchist.wooz.org>

FWIW, this would probably be better on python-dev, but maybe you wanted to cut
down on potential noise and churn?

On Jan 06, 2014, at 01:34 PM, Larry Hastings wrote:

>The thing is, I feel like this is borderline between bug fix and new feature.
>But without adding this, we would make a lot of the Argument Clinic
>conversions pretty messy.  So I want to check it in.  I just don't want to
>piss everybody off in the process.
>
>Can you guys live with this?

I sure can.  To me, AC is "the new feature" and as we continue to adopt it in
Python 3.4, we'll find more corner cases like this one.  Better to do what we
can to improve the situation now rather than have to wait until 3.5.

-Barry

From larry at hastings.org  Mon Jan  6 23:50:09 2014
From: larry at hastings.org (Larry Hastings)
Date: Mon, 06 Jan 2014 14:50:09 -0800
Subject: [python-committers] Adding a (small) feature to 3.4 for
 Argument Clinic: inspect.Signature supporting simple named constants for
 default values
In-Reply-To: <52CB29EE.1010800@egenix.com>
References: <52CB2162.2090506@hastings.org> <52CB29EE.1010800@egenix.com>
Message-ID: <52CB3321.5030803@hastings.org>

On 01/06/2014 02:10 PM, M.-A. Lemburg wrote:
> Looks like a documentation bug to me. Several functions were changed 
> to be keyword aware some years ago and the docs you quoted still list 
> the old positional format. 

Your intuition was spot on.  Revision 0a97f5dde3a7, by the effbot, Tue 
Oct 03 2000.

Tsk tsk, effbot,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140106/c4a10fc3/attachment-0001.html>

From michael at voidspace.org.uk  Tue Jan  7 00:07:32 2014
From: michael at voidspace.org.uk (Michael Foord)
Date: Mon, 6 Jan 2014 23:07:32 +0000
Subject: [python-committers] PyCon Language Summit: Wednesday 9th April
In-Reply-To: <CAMpsgwbmx=9iVxhnbAOso3F7z3X=5eOY37Z1EckO08sRb-P8FA@mail.gmail.com>
References: <C533EC9B-5207-44C7-9A35-81E35639A963@voidspace.org.uk>
 <CAMpsgwbmx=9iVxhnbAOso3F7z3X=5eOY37Z1EckO08sRb-P8FA@mail.gmail.com>
Message-ID: <29ACEA00-5536-41A0-925A-C982A22F7A8D@voidspace.org.uk>


On 6 Jan 2014, at 10:35, Victor Stinner <victor.stinner at gmail.com> wrote:

> Hi,
> 
> 2013/12/4 Michael Foord <michael at voidspace.org.uk>:
>> As with previous years we will be having a Language Summit at PyCon North America, in Montreal. The summit will be on Wednesday 9th April and running from approximately 10am to 4pm.
> 
> My talk "Track memory leaks in Python" was accepted, I will be present
> at Montreal for Pycon US \o/
> 
> For the summit, I think that we must discuss the adoption of Python 3
> and try to fix remaining issues to ease porting applications from
> Python 2 to Python 3. Mercurial and Twisted are not ported yet, and
> some developers consider Python 3 as a mistake. You must try to
> understand why and fix remaining issues.
> 
> One concrete point is the "support .format for bytes" which was
> requested by Mercurial ("for Mercurial this is the single biggest
> impediment to even getting our testrunner working, much less starting
> the porting process.") and Twisted ("Honestly, what Twisted is mostly
> after is a way to write code that works both with Python 2 and Python
> 3.")
> http://bugs.python.org/issue3982
> 
> A PEP was requested for this issue, I'm interested to help to write it
> and implement it in Python 3.5.
> 
> A Python 2.8 version was also proposed to reduce differences between
> Python 2 and 3, and so ease porting applications to Python 3. Related
> discussion:
> 
> "About Python 3"
> http://alexgaynor.net/2013/dec/30/about-python-3/
> 
> "Debating a "transitional" Python 2.8"
> http://lwn.net/Articles/578532/
> Free link if you are not subscribed:
> http://lwn.net/SubscriberLink/578532/8002e0bc4289a23d/
> 
> This mailing list is not the right place to discuss all these points,
> I propose to discuss them during the Language Summit. If you would
> like to discuss these points right now, please open a discussion in
> python-dev or python-ideas.
> 


Thanks for letting me know Victor. I've added you to the list of attendees and added your items to the agenda.

Michael

> Victor


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html






From ethan at stoneleaf.us  Mon Jan  6 23:35:46 2014
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 06 Jan 2014 14:35:46 -0800
Subject: [python-committers] Adding a (small) feature to 3.4 for
 Argument Clinic: inspect.Signature supporting simple named constants for
 default values
In-Reply-To: <20140106172114.493d4ce7@anarchist.wooz.org>
References: <52CB2162.2090506@hastings.org>
 <20140106172114.493d4ce7@anarchist.wooz.org>
Message-ID: <52CB2FC2.6040409@stoneleaf.us>

On 01/06/2014 02:21 PM, Barry Warsaw wrote:
> On Jan 06, 2014, at 01:34 PM, Larry Hastings wrote:
>
>> The thing is, I feel like this is borderline between bug fix and new feature.
>> But without adding this, we would make a lot of the Argument Clinic
>> conversions pretty messy.  So I want to check it in.  I just don't want to
>> piss everybody off in the process.
>>
>> Can you guys live with this?
>
> I sure can.  To me, AC is "the new feature" and as we continue to adopt it in
> Python 3.4, we'll find more corner cases like this one.  Better to do what we
> can to improve the situation now rather than have to wait until 3.5.

Agreed.

--
~Ethan~

From ncoghlan at gmail.com  Tue Jan  7 01:13:12 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 7 Jan 2014 10:13:12 +1000
Subject: [python-committers] Adding a (small) feature to 3.4 for
 Argument Clinic: inspect.Signature supporting simple named constants for
 default values
In-Reply-To: <52CB2FC2.6040409@stoneleaf.us>
References: <52CB2162.2090506@hastings.org>
 <20140106172114.493d4ce7@anarchist.wooz.org>
 <52CB2FC2.6040409@stoneleaf.us>
Message-ID: <CADiSq7cFjyZ1i=QZrQFG_ydGHGohtpey0YmwwybQXrK2PSdVXQ@mail.gmail.com>

On 7 Jan 2014 07:34, "Ethan Furman" <ethan at stoneleaf.us> wrote:
>
> On 01/06/2014 02:21 PM, Barry Warsaw wrote:
>>
>> On Jan 06, 2014, at 01:34 PM, Larry Hastings wrote:
>>
>>> The thing is, I feel like this is borderline between bug fix and new
feature.
>>> But without adding this, we would make a lot of the Argument Clinic
>>> conversions pretty messy.  So I want to check it in.  I just don't want
to
>>> piss everybody off in the process.
>>>
>>> Can you guys live with this?
>>
>>
>> I sure can.  To me, AC is "the new feature" and as we continue to adopt
it in
>> Python 3.4, we'll find more corner cases like this one.  Better to do
what we
>> can to improve the situation now rather than have to wait until 3.5.
>
>
> Agreed.

Same from me. I see it as similar to ensurepip and the import changes - as
we've been fully incorporating those, we noticed some edge cases and API
issues that we want to tweak before the first release candidate.

Cheers,
Nick.

>
> --
> ~Ethan~
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140107/1120d49f/attachment.html>

From tjreedy at udel.edu  Tue Jan  7 02:18:53 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 06 Jan 2014 20:18:53 -0500
Subject: [python-committers] Adding a (small) feature to 3.4 for
 Argument Clinic: inspect.Signature supporting simple named constants for
 default values
In-Reply-To: <20140106172114.493d4ce7@anarchist.wooz.org>
References: <52CB2162.2090506@hastings.org>
 <20140106172114.493d4ce7@anarchist.wooz.org>
Message-ID: <52CB55FD.9070809@udel.edu>

On 1/6/2014 5:21 PM, Barry Warsaw wrote:
> FWIW, this would probably be better on python-dev, but maybe you wanted to cut
> down on potential noise and churn?

Better here, I think.

> On Jan 06, 2014, at 01:34 PM, Larry Hastings wrote:
>
>> The thing is, I feel like this is borderline between bug fix and new feature.
>> But without adding this, we would make a lot of the Argument Clinic
>> conversions pretty messy.  So I want to check it in.  I just don't want to
>> piss everybody off in the process.
>>
>> Can you guys live with this?
>
> I sure can.  To me, AC is "the new feature" and as we continue to adopt it in
> Python 3.4, we'll find more corner cases like this one.  Better to do what we
> can to improve the situation now rather than have to wait until 3.5.

I agree with Barry. To my understanding, the reason for the internal 
'feature freeze' with beta 0, with betas yet to come, is so that we can 
test new API's and *possibly adjust the details*, based on experience, 
before the final ..0 release and public feature freeze. All new features 
are provisional until then (we could rip out a new feature), which is 
why betas are not for production use, even if they are otherwise the 
best release available for some purposes. The fix versus feature 
question, for changes to the new feature, comes into play again after 
..0, when considering ..1, etc.

Terry


From eliben at gmail.com  Tue Jan  7 22:18:26 2014
From: eliben at gmail.com (Eli Bendersky)
Date: Tue, 7 Jan 2014 13:18:26 -0800
Subject: [python-committers] clinic churn after beta2
Message-ID: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>

Hello,

Does it really make sense to introduce large amounts of code churn after
the release of 3.4 beta2? It started innocently enough, but now it seems
that the whole implementation is being reconsidered (Antoine's email to
pydev). This doesn't look like something we should be doing so late in the
release process.

Are we really that much in need of convert-to-clinic *now*?

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140107/2117c7b4/attachment.html>

From victor.stinner at gmail.com  Tue Jan  7 22:26:20 2014
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 7 Jan 2014 22:26:20 +0100
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
Message-ID: <CAMpsgwZRNBUb60jOLRkNODNhqqytNst-zH6-OvKwSzjUOQLN_Q@mail.gmail.com>

2014/1/7 Eli Bendersky <eliben at gmail.com>:
> Are we really that much in need of convert-to-clinic *now*?

Why not creating the 3.4 branch after the beta1 and develop Python 3.5
in default during the stabilisation process of Python 3.4? It's like
many other softwares are developed.

Only bugfixes would be accepted in the branch 3.4, as we do currently
with 3.3 branch.

Victor

From eliben at gmail.com  Tue Jan  7 22:30:01 2014
From: eliben at gmail.com (Eli Bendersky)
Date: Tue, 7 Jan 2014 13:30:01 -0800
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CAMpsgwZRNBUb60jOLRkNODNhqqytNst-zH6-OvKwSzjUOQLN_Q@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <CAMpsgwZRNBUb60jOLRkNODNhqqytNst-zH6-OvKwSzjUOQLN_Q@mail.gmail.com>
Message-ID: <CAF-Rda-e2sMKUXQ1pnB4KwmN6oeaKfnsPxFRrMRDcZ5MTOujvQ@mail.gmail.com>

On Tue, Jan 7, 2014 at 1:26 PM, Victor Stinner <victor.stinner at gmail.com>wrote:

> 2014/1/7 Eli Bendersky <eliben at gmail.com>:
> > Are we really that much in need of convert-to-clinic *now*?
>
> Why not creating the 3.4 branch after the beta1 and develop Python 3.5
> in default during the stabilisation process of Python 3.4? It's like
> many other softwares are developed.
>
> Only bugfixes would be accepted in the branch 3.4, as we do currently
> with 3.3 branch.
>
>
I asked this exact question a few weeks ago, but got the answer that this
is the way Python does it. Fair enough, but huge amount of churn generated
by a not-yet-decided-how-it-should-work Argument Clinic is really unrelated
and totally out of place between beta2 and the final release of a major
Python version.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140107/c251d5b5/attachment.html>

From greg at krypto.org  Tue Jan  7 22:31:52 2014
From: greg at krypto.org (Gregory P. Smith)
Date: Tue, 7 Jan 2014 13:31:52 -0800
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
Message-ID: <CAGE7PN+U4R95SwJz9TrpRf3vG+u_yxzCREJ3GrLjoZV-DGPjYA@mail.gmail.com>

On Tue, Jan 7, 2014 at 1:18 PM, Eli Bendersky <eliben at gmail.com> wrote:

> Hello,
>
> Does it really make sense to introduce large amounts of code churn after
> the release of 3.4 beta2? It started innocently enough, but now it seems
> that the whole implementation is being reconsidered (Antoine's email to
> pydev). This doesn't look like something we should be doing so late in the
> release process.
>

I wouldn't call that a whole implementation being reconsidered. People are
just bike shedding over which wall to paint first. The color has already
been established.

Besides, Larry is both the release manager for 3.4 and argument clinic
proponent. If we need a beta3 instead of an rc1 next, that is up to him. :)

I'm not weighing in on the pydev thread despite having opinions because it
just doesn't matter to me in the end. I'd just be adding noise and am happy
to accept anything so long as argument clinic does stay in for 3.4.


> Are we really that much in need of convert-to-clinic *now*?
>

It'll never happen otherwise.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140107/30d4327f/attachment.html>

From solipsis at pitrou.net  Tue Jan  7 22:33:36 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 07 Jan 2014 22:33:36 +0100
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
Message-ID: <1389130416.2286.16.camel@fsol>

On mar., 2014-01-07 at 13:18 -0800, Eli Bendersky wrote:
> Hello,
> 
> Does it really make sense to introduce large amounts of code churn
> after the release of 3.4 beta2? It started innocently enough, but now
> it seems that the whole implementation is being reconsidered
> (Antoine's email to pydev). This doesn't look like something we should
> be doing so late in the release process.
> 
> Are we really that much in need of convert-to-clinic *now*?

I guess the question is: are there large enough benefits to be reaped
for risking the release (a bit)?
There's no question Argument Clinic can bring interesting benefits, it's
just a question of timing.

Regards

Antoine.




From lukasz at langa.pl  Tue Jan  7 22:42:29 2014
From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=)
Date: Tue, 7 Jan 2014 13:42:29 -0800
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <1389130416.2286.16.camel@fsol>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
Message-ID: <400D4634-DD32-4F71-98E2-34F5E62C7921@langa.pl>

On Jan 7, 2014, at 1:33 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On mar., 2014-01-07 at 13:18 -0800, Eli Bendersky wrote:
>> Hello,
>> 
>> Does it really make sense to introduce large amounts of code churn
>> after the release of 3.4 beta2? It started innocently enough, but now
>> it seems that the whole implementation is being reconsidered
>> (Antoine's email to pydev). This doesn't look like something we should
>> be doing so late in the release process.
>> 
>> Are we really that much in need of convert-to-clinic *now*?
> 
> I guess the question is: are there large enough benefits to be reaped
> for risking the release (a bit)?
> There's no question Argument Clinic can bring interesting benefits, it's
> just a question of timing.

Let me play the devil?s advocate here: how much do we risk in future
maintainability costs if we move to Argument Clinic in Python 3.5 and
leave large parts of Python 3.4 uncovered by it?

I mean that we can get some ugly diffs between code using Argument Clinic
and manual argument parsing.

-- 
Best regards,
?ukasz Langa

WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev


From ethan at stoneleaf.us  Tue Jan  7 22:24:02 2014
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 07 Jan 2014 13:24:02 -0800
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
Message-ID: <52CC7072.40104@stoneleaf.us>

On 01/07/2014 01:18 PM, Eli Bendersky wrote:
>
> Does it really make sense to introduce large amounts of code churn after the release of 3.4 beta2? It started innocently
> enough, but now it seems that the whole implementation is being reconsidered (Antoine's email to pydev). This doesn't
> look like something we should be doing so late in the release process.
>
> Are we really that much in need of convert-to-clinic *now*?

Making help more helpful is a huge win, and the time to hammer out the bugs in AC is definitely now.

--
~Ethan~

From brett at python.org  Tue Jan  7 23:11:49 2014
From: brett at python.org (Brett Cannon)
Date: Tue, 7 Jan 2014 17:11:49 -0500
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CAGE7PN+U4R95SwJz9TrpRf3vG+u_yxzCREJ3GrLjoZV-DGPjYA@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <CAGE7PN+U4R95SwJz9TrpRf3vG+u_yxzCREJ3GrLjoZV-DGPjYA@mail.gmail.com>
Message-ID: <CAP1=2W5m0T9NF7emSZaAZib9M8Fqt8tcj2SAbGhB__TDo-tBHw@mail.gmail.com>

On Tue, Jan 7, 2014 at 4:31 PM, Gregory P. Smith <greg at krypto.org> wrote:

>
> On Tue, Jan 7, 2014 at 1:18 PM, Eli Bendersky <eliben at gmail.com> wrote:
>
>> Hello,
>>
>> Does it really make sense to introduce large amounts of code churn after
>> the release of 3.4 beta2? It started innocently enough, but now it seems
>> that the whole implementation is being reconsidered (Antoine's email to
>> pydev). This doesn't look like something we should be doing so late in the
>> release process.
>>
>
> I wouldn't call that a whole implementation being reconsidered. People are
> just bike shedding over which wall to paint first. The color has already
> been established.
>

Agreed.


>
> Besides, Larry is both the release manager for 3.4 and argument clinic
> proponent. If we need a beta3 instead of an rc1 next, that is up to him. :)
>

Exactly. It also helps that this is not meant to change semantics (beyond
better help() ATM) so unit tests + compiler checks should be enough to
catch any major issues that Argument Clinic might cause.


>
> I'm not weighing in on the pydev thread despite having opinions because it
> just doesn't matter to me in the end. I'd just be adding noise and am happy
> to accept anything so long as argument clinic does stay in for 3.4.
>
>
>> Are we really that much in need of convert-to-clinic *now*?
>>
>
> It'll never happen otherwise.
>

I see no reason not to get it done now. I would honestly say we should push
the release to see it finished so we don't end up with some C code
converted and not others. Might as well get all extension code to have
defined signatures than only some at this point.

-Brett


>
> -gps
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140107/b4f19862/attachment.html>

From storchaka at gmail.com  Tue Jan  7 23:13:57 2014
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 08 Jan 2014 00:13:57 +0200
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <400D4634-DD32-4F71-98E2-34F5E62C7921@langa.pl>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <400D4634-DD32-4F71-98E2-34F5E62C7921@langa.pl>
Message-ID: <1404492.05ESs8RCxv@raxxla>

????????, 07-???-2014 13:42:29 ?ukasz Langa ????????:
> Let me play the devil?s advocate here: how much do we risk in future
> maintainability costs if we move to Argument Clinic in Python 3.5 and
> leave large parts of Python 3.4 uncovered by it?
> 
> I mean that we can get some ugly diffs between code using Argument Clinic
> and manual argument parsing.

As between clinicalized 3.4 and 3.3 or 2.7?


From eliben at gmail.com  Tue Jan  7 23:37:22 2014
From: eliben at gmail.com (Eli Bendersky)
Date: Tue, 7 Jan 2014 14:37:22 -0800
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <1389130416.2286.16.camel@fsol>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
Message-ID: <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>

On Tue, Jan 7, 2014 at 1:33 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On mar., 2014-01-07 at 13:18 -0800, Eli Bendersky wrote:
> > Hello,
> >
> > Does it really make sense to introduce large amounts of code churn
> > after the release of 3.4 beta2? It started innocently enough, but now
> > it seems that the whole implementation is being reconsidered
> > (Antoine's email to pydev). This doesn't look like something we should
> > be doing so late in the release process.
> >
> > Are we really that much in need of convert-to-clinic *now*?
>
> I guess the question is: are there large enough benefits to be reaped
> for risking the release (a bit)?
> There's no question Argument Clinic can bring interesting benefits, it's
> just a question of timing.
>

Just to be clear, this is exactly what I mean. I'm not saying AC is not
worth it; I'm questioning the timing.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140107/9a5ab844/attachment.html>

From amk at amk.ca  Wed Jan  8 00:10:40 2014
From: amk at amk.ca (A.M. Kuchling)
Date: Tue, 7 Jan 2014 18:10:40 -0500
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
Message-ID: <20140107231040.GA62752@datlandrewk.home>

On Tue, Jan 07, 2014 at 02:37:22PM -0800, Eli Bendersky wrote:
> Just to be clear, this is exactly what I mean. I'm not saying AC is not
> worth it; I'm questioning the timing.

Agreed; let's try to avoid far-ranging sets of changes so late in the
beta cycle.

If we want to send 3.4 back to alpha and implement some form of
string-formatting changes and Argument Clinic, that would be fine,
though it might mean Ubuntu and other Linux distros might have to ship
with 3.3 again because 3.4 wasn't done in time.

--amk

From ncoghlan at gmail.com  Wed Jan  8 01:29:03 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 8 Jan 2014 10:29:03 +1000
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <20140107231040.GA62752@datlandrewk.home>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
Message-ID: <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>

On 8 Jan 2014 07:11, "A.M. Kuchling" <amk at amk.ca> wrote:
>
> On Tue, Jan 07, 2014 at 02:37:22PM -0800, Eli Bendersky wrote:
> > Just to be clear, this is exactly what I mean. I'm not saying AC is not
> > worth it; I'm questioning the timing.
>
> Agreed; let's try to avoid far-ranging sets of changes so late in the
> beta cycle.
>
> If we want to send 3.4 back to alpha and implement some form of
> string-formatting changes and Argument Clinic, that would be fine,
> though it might mean Ubuntu and other Linux distros might have to ship
> with 3.3 again because 3.4 wasn't done in time.

The bytes formatting change is right out. It likely requires the use of the
3.3 or 2.7 bytestring formatting code as the basis and should be feasible
to implement and publish as a function in a cross-version PyPI library
before locking in the syntax and semantics for Python 3.5, so I see zero
justification for delaying Python 3.4 on that basis. It's relevant to the
question of encouraging migrations from Python 2 (as current Python
developers are used to having a feature like that available), but is not
especially significant in terms of encouraging *new* development in Python
3 (since it's a relatively obscure use case with multiple alternative
approaches available).

Back on topic for the thread, the argument clinic conversions seem unlikely
to introduce *subtle* bugs that the test suite misses, so it doesn't bother
me that Larry is encouraging such changes as part of the beta cycle. If an
extra beta or release candidate ends being needed, so be it, but I'm happy
to leave that call to Larry as release manager.

Cheers,
Nick.

> --amk
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140108/af167324/attachment.html>

From benjamin at python.org  Wed Jan  8 01:33:28 2014
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 07 Jan 2014 16:33:28 -0800
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
Message-ID: <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>

On Tue, Jan 7, 2014, at 04:29 PM, Nick Coghlan wrote:
> On 8 Jan 2014 07:11, "A.M. Kuchling" <amk at amk.ca> wrote:
> >
> > On Tue, Jan 07, 2014 at 02:37:22PM -0800, Eli Bendersky wrote:
> > > Just to be clear, this is exactly what I mean. I'm not saying AC is not
> > > worth it; I'm questioning the timing.
> >
> > Agreed; let's try to avoid far-ranging sets of changes so late in the
> > beta cycle.
> >
> > If we want to send 3.4 back to alpha and implement some form of
> > string-formatting changes and Argument Clinic, that would be fine,
> > though it might mean Ubuntu and other Linux distros might have to ship
> > with 3.3 again because 3.4 wasn't done in time.
> 
> The bytes formatting change is right out. It likely requires the use of
> the
> 3.3 or 2.7 bytestring formatting code as the basis and should be feasible
> to implement and publish as a function in a cross-version PyPI library
> before locking in the syntax and semantics for Python 3.5, so I see zero
> justification for delaying Python 3.4 on that basis. It's relevant to the
> question of encouraging migrations from Python 2 (as current Python
> developers are used to having a feature like that available), but is not
> especially significant in terms of encouraging *new* development in
> Python
> 3 (since it's a relatively obscure use case with multiple alternative
> approaches available).

A PyPI module is not so great because you'll have to change every
formatting operation to use a function from a module rather than the %
operator or the format method.

From eric at trueblade.com  Wed Jan  8 01:39:19 2014
From: eric at trueblade.com (Eric V. Smith)
Date: Tue, 07 Jan 2014 19:39:19 -0500
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
Message-ID: <52CC9E37.9090900@trueblade.com>

On 1/7/2014 7:33 PM, Benjamin Peterson wrote:
> A PyPI module is not so great because you'll have to change every
> formatting operation to use a function from a module rather than the %
> operator or the format method.

I think this is the crux of the issue. Are we trying to say "porting
your existing code will be easier", or "change your existing code to
this new library, and we'll provide the library on 2.x and 3.y" (for
some values of x and y).

I think the former is the right way to go, but I also think if we do
that we should shoot for 3.4, and this would necessitate a delay in 3.4.
Providing this feature for 3.5 might be too late for the target audience
of code porters.

Eric.


From larry at hastings.org  Wed Jan  8 01:58:17 2014
From: larry at hastings.org (Larry Hastings)
Date: Tue, 07 Jan 2014 16:58:17 -0800
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <20140107231040.GA62752@datlandrewk.home>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
Message-ID: <52CCA2A9.40400@hastings.org>

On 01/07/2014 03:10 PM, A.M. Kuchling wrote:
> On Tue, Jan 07, 2014 at 02:37:22PM -0800, Eli Bendersky wrote:
>> Just to be clear, this is exactly what I mean. I'm not saying AC is not
>> worth it; I'm questioning the timing.
> Agreed; let's try to avoid far-ranging sets of changes so late in the
> beta cycle.
>
> If we want to send 3.4 back to alpha and implement some form of
> string-formatting changes and Argument Clinic, that would be fine,
> though it might mean Ubuntu and other Linux distros might have to ship
> with 3.3 again because 3.4 wasn't done in time.

I hadn't considered slipping the release, but that does seem like an 
entirely sane idea.  However, I'm not proposing slipping back to alpha 
so we can add the cause-celebre-of-the-week bytes formatting stuff, and 
we don't need to slip all the way back to alpha for Argument Clinic.  A 
third beta seems entirely reasonable though. Let's try the derby for a 
couple of days and see how we feel.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140107/492610c9/attachment.html>

From greg at krypto.org  Wed Jan  8 02:43:19 2014
From: greg at krypto.org (Gregory P. Smith)
Date: Tue, 7 Jan 2014 17:43:19 -0800
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <52CCA2A9.40400@hastings.org>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home> <52CCA2A9.40400@hastings.org>
Message-ID: <CAGE7PN+_EKtPuFfjYKmmQtJH0RSDDG7Atb_2_Qc_r9nuLtWk+w@mail.gmail.com>

On Tue, Jan 7, 2014 at 4:58 PM, Larry Hastings <larry at hastings.org> wrote:

>  On 01/07/2014 03:10 PM, A.M. Kuchling wrote:
>
> On Tue, Jan 07, 2014 at 02:37:22PM -0800, Eli Bendersky wrote:
>
>  Just to be clear, this is exactly what I mean. I'm not saying AC is not
> worth it; I'm questioning the timing.
>
>  Agreed; let's try to avoid far-ranging sets of changes so late in the
> beta cycle.
>
> If we want to send 3.4 back to alpha and implement some form of
> string-formatting changes and Argument Clinic, that would be fine,
> though it might mean Ubuntu and other Linux distros might have to ship
> with 3.3 again because 3.4 wasn't done in time.
>
>
> I hadn't considered slipping the release, but that does seem like an
> entirely sane idea.  However, I'm not proposing slipping back to alpha so
> we can add the cause-celebre-of-the-week bytes formatting stuff, and we
> don't need to slip all the way back to alpha for Argument Clinic.  A third
> beta seems entirely reasonable though.  Let's try the derby for a couple of
> days and see how we feel.
>
>
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140107/68dcf814/attachment-0001.html>

From ncoghlan at gmail.com  Wed Jan  8 03:06:09 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 8 Jan 2014 12:06:09 +1000
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <52CC9E37.9090900@trueblade.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
Message-ID: <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>

On 8 Jan 2014 08:44, "Eric V. Smith" <eric at trueblade.com> wrote:
>
> On 1/7/2014 7:33 PM, Benjamin Peterson wrote:
> > A PyPI module is not so great because you'll have to change every
> > formatting operation to use a function from a module rather than the %
> > operator or the format method.
>
> I think this is the crux of the issue. Are we trying to say "porting
> your existing code will be easier", or "change your existing code to
> this new library, and we'll provide the library on 2.x and 3.y" (for
> some values of x and y).
>
> I think the former is the right way to go, but I also think if we do
> that we should shoot for 3.4, and this would necessitate a delay in 3.4.
> Providing this feature for 3.5 might be too late for the target audience
> of code porters.

I'm saying hacking in a complex change in a few weeks when there isn't
consensus even on the basics of the design just because a few moderately
high profile developers failed to understand what "5 years to be the
default choice for new projects" meant would be the height of
irresponsibility. Create the module, figure out the exact formatting
mini-language and semantics, post it on PyPI where compatibility modules
like six and future can get at it, and *then* propose syntactic/builtin
support for 3.5.

The 5 year goal was for the Python 3 ecosystem to be a sufficiently
functionally complete alternative to Python 2 for it to be recommended by
default for every use case where Python 2 wasn't already being used.

Addressing the key remaining barriers to migration for existing Python 2
users would be an excellent objective to attain before we end upstream
support for Python 2.7, but it's one that would be better addressed by a
slightly shorter dev cycle than normal for 3.5 than it would be by falling
into the "just one more feature" trap for Python 3.4.

Cheers,
Nick.

>
> Eric.
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140108/ad8b22f3/attachment.html>

From benjamin at python.org  Wed Jan  8 03:23:51 2014
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 07 Jan 2014 18:23:51 -0800
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
 <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
Message-ID: <1389147831.31887.67936897.239242BF@webmail.messagingengine.com>

On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
> On 8 Jan 2014 08:44, "Eric V. Smith" <eric at trueblade.com> wrote:
> >
> > On 1/7/2014 7:33 PM, Benjamin Peterson wrote:
> > > A PyPI module is not so great because you'll have to change every
> > > formatting operation to use a function from a module rather than the %
> > > operator or the format method.
> >
> > I think this is the crux of the issue. Are we trying to say "porting
> > your existing code will be easier", or "change your existing code to
> > this new library, and we'll provide the library on 2.x and 3.y" (for
> > some values of x and y).
> >
> > I think the former is the right way to go, but I also think if we do
> > that we should shoot for 3.4, and this would necessitate a delay in 3.4.
> > Providing this feature for 3.5 might be too late for the target audience
> > of code porters.
> 
> I'm saying hacking in a complex change in a few weeks when there isn't
> consensus even on the basics of the design just because a few moderately
> high profile developers failed to understand what "5 years to be the
> default choice for new projects" meant would be the height of
> irresponsibility.

It's not design from scratch, since it should be fairly close to the 2.x
string formatting mini-languages.

> 
> The 5 year goal was for the Python 3 ecosystem to be a sufficiently
> functionally complete alternative to Python 2 for it to be recommended by
> default for every use case where Python 2 wasn't already being used.
> 
> Addressing the key remaining barriers to migration for existing Python 2
> users would be an excellent objective to attain before we end upstream
> support for Python 2.7, but it's one that would be better addressed by a
> slightly shorter dev cycle than normal for 3.5 than it would be by
> falling
> into the "just one more feature" trap for Python 3.4.

I think a shorter cycle for 3.5 is fine, too.

From larry at hastings.org  Wed Jan  8 03:35:47 2014
From: larry at hastings.org (Larry Hastings)
Date: Tue, 07 Jan 2014 18:35:47 -0800
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
 <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
Message-ID: <52CCB983.5080201@hastings.org>

On 01/07/2014 06:06 PM, Nick Coghlan wrote:
>
> Addressing the key remaining barriers to migration for existing Python 
> 2 users would be an excellent objective to attain before we end 
> upstream support for Python 2.7, but it's one that would be better 
> addressed by a slightly shorter dev cycle than normal for 3.5 than it 
> would be by falling into the "just one more feature" trap for Python 3.4.
>

I was thinking about that myself.  If we said in advance what features 
we were shooting for, and it wasn't overly ambitious, we could do a 
release in six months.  No problem.

Do we know of any (other) big projects waiting to happen for 3.5?

And has a consensus about byte formatting really coalesced that quickly?


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140107/5d72cb36/attachment.html>

From tjreedy at udel.edu  Wed Jan  8 05:51:18 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 07 Jan 2014 23:51:18 -0500
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <52CCB983.5080201@hastings.org>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
 <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
 <52CCB983.5080201@hastings.org>
Message-ID: <52CCD946.2090004@udel.edu>

On 1/7/2014 9:35 PM, Larry Hastings wrote:
> On 01/07/2014 06:06 PM, Nick Coghlan wrote:
>>
>> Addressing the key remaining barriers to migration for existing Python
>> 2 users would be an excellent objective to attain before we end
>> upstream support for Python 2.7, but it's one that would be better
>> addressed by a slightly shorter dev cycle than normal for 3.5 than it
>> would be by falling into the "just one more feature" trap for Python 3.4.
>>
>
> I was thinking about that myself.  If we said in advance what features
> we were shooting for, and it wasn't overly ambitious, we could do a
> release in six months.  No problem.
>
> Do we know of any (other) big projects waiting to happen for 3.5?

Integration of regex module?
>
> And has a consensus about byte formatting really coalesced that quickly?

I don't think so. Guido suggested a minimal method and I coded a Python 
version of a version of that. But many would like *their* favorite 
feature added. I would like to see a new method tested by, say, 
mercurial. I also think there are separate questions as to what we want 
in 3.x for writing 3.x code and what in needed for writing polyglot 2 
and 3 code. If the requirements are not the same, I think multi-version 
modules on Pypi (existing and planned) may in some cases be the better 
way to go.

Terry



From ncoghlan at gmail.com  Wed Jan  8 08:39:59 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 8 Jan 2014 17:39:59 +1000
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <52CCB983.5080201@hastings.org>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
 <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
 <52CCB983.5080201@hastings.org>
Message-ID: <CADiSq7drm4L+JZ_u=-VrcScmbU7=wnph3u41u1mR3hVgkbw4fQ@mail.gmail.com>

On 8 Jan 2014 10:36, "Larry Hastings" <larry at hastings.org> wrote:
>
> On 01/07/2014 06:06 PM, Nick Coghlan wrote:
>>
>> Addressing the key remaining barriers to migration for existing Python 2
users would be an excellent objective to attain before we end upstream
support for Python 2.7, but it's one that would be better addressed by a
slightly shorter dev cycle than normal for 3.5 than it would be by falling
into the "just one more feature" trap for Python 3.4.
>
>
> I was thinking about that myself.  If we said in advance what features we
were shooting for, and it wasn't overly ambitious, we could do a release in
six months.  No problem.
>
> Do we know of any (other) big projects waiting to happen for 3.5?

Extending the PEP 451 import model to allow true reloading of extension
modules and the PEP 422 replacement for dynamic metaclass definitions.

Also some tweaks to standard stream configuration, support for changing the
encoding of a stream and a public API for codecs to declare "I am not a
text encoding".

I suspect a 6 month cycle would confuse users and inconvenience
redistributors, but a 12?17 month cycle so 3.5 is published before 2.7
enters security fix only mode would make a *lot* of sense.

Cheers,
Nick.

>
> And has a consensus about byte formatting really coalesced that quickly?
>
>
> /arry
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140108/c3f890b5/attachment-0001.html>

From g.brandl at gmx.net  Wed Jan  8 10:07:05 2014
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 08 Jan 2014 10:07:05 +0100
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <1389147831.31887.67936897.239242BF@webmail.messagingengine.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
 <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
 <1389147831.31887.67936897.239242BF@webmail.messagingengine.com>
Message-ID: <laj4e4$hs9$1@ger.gmane.org>

Am 08.01.2014 03:23, schrieb Benjamin Peterson:
> On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
>> On 8 Jan 2014 08:44, "Eric V. Smith" <eric at trueblade.com> wrote:
>> >
>> > On 1/7/2014 7:33 PM, Benjamin Peterson wrote:
>> > > A PyPI module is not so great because you'll have to change every
>> > > formatting operation to use a function from a module rather than the %
>> > > operator or the format method.
>> >
>> > I think this is the crux of the issue. Are we trying to say "porting
>> > your existing code will be easier", or "change your existing code to
>> > this new library, and we'll provide the library on 2.x and 3.y" (for
>> > some values of x and y).
>> >
>> > I think the former is the right way to go, but I also think if we do
>> > that we should shoot for 3.4, and this would necessitate a delay in 3.4.
>> > Providing this feature for 3.5 might be too late for the target audience
>> > of code porters.
>> 
>> I'm saying hacking in a complex change in a few weeks when there isn't
>> consensus even on the basics of the design just because a few moderately
>> high profile developers failed to understand what "5 years to be the
>> default choice for new projects" meant would be the height of
>> irresponsibility.
> 
> It's not design from scratch, since it should be fairly close to the 2.x
> string formatting mini-languages.

Yes, I think the feature set should be settled upon quickly.

>> The 5 year goal was for the Python 3 ecosystem to be a sufficiently
>> functionally complete alternative to Python 2 for it to be recommended by
>> default for every use case where Python 2 wasn't already being used.
>> 
>> Addressing the key remaining barriers to migration for existing Python 2
>> users would be an excellent objective to attain before we end upstream
>> support for Python 2.7, but it's one that would be better addressed by a
>> slightly shorter dev cycle than normal for 3.5 than it would be by
>> falling
>> into the "just one more feature" trap for Python 3.4.
> 
> I think a shorter cycle for 3.5 is fine, too.

Great!  I agree with Nick that 6 months is too short, but I would definitely
start with betas after 6 months.

Georg


From ncoghlan at gmail.com  Wed Jan  8 11:08:29 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 8 Jan 2014 20:08:29 +1000
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <laj4e4$hs9$1@ger.gmane.org>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
 <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
 <1389147831.31887.67936897.239242BF@webmail.messagingengine.com>
 <laj4e4$hs9$1@ger.gmane.org>
Message-ID: <CADiSq7d0a1BTpuDSCRXVtWbhEB6RKaZWn2=WjqvCVUE4tmF7+Q@mail.gmail.com>

On 8 Jan 2014 17:06, "Georg Brandl" <g.brandl at gmx.net> wrote:
>
> Am 08.01.2014 03:23, schrieb Benjamin Peterson:
> > On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
> >> On 8 Jan 2014 08:44, "Eric V. Smith" <eric at trueblade.com> wrote:
> >> >
> >> > On 1/7/2014 7:33 PM, Benjamin Peterson wrote:
> >> > > A PyPI module is not so great because you'll have to change every
> >> > > formatting operation to use a function from a module rather than
the %
> >> > > operator or the format method.
> >> >
> >> > I think this is the crux of the issue. Are we trying to say "porting
> >> > your existing code will be easier", or "change your existing code to
> >> > this new library, and we'll provide the library on 2.x and 3.y" (for
> >> > some values of x and y).
> >> >
> >> > I think the former is the right way to go, but I also think if we do
> >> > that we should shoot for 3.4, and this would necessitate a delay in
3.4.
> >> > Providing this feature for 3.5 might be too late for the target
audience
> >> > of code porters.
> >>
> >> I'm saying hacking in a complex change in a few weeks when there isn't
> >> consensus even on the basics of the design just because a few
moderately
> >> high profile developers failed to understand what "5 years to be the
> >> default choice for new projects" meant would be the height of
> >> irresponsibility.
> >
> > It's not design from scratch, since it should be fairly close to the 2.x
> > string formatting mini-languages.
>
> Yes, I think the feature set should be settled upon quickly.

I'm not yet convinced restoring more string-like behaviour to bytes is a
better solution than a dedicated type specifically for working with ASCII
compatible wire protocols (that approach is still being kicked around as a
possibility in the parallel discussion on python-ideas).

One key advantage of such a type is that it could be designed to make "text
or ASCII bytes" code like the URL parsing as straightforward to write as it
was in Python 2, whereas adding formatting to bytes objects wouldn't help
with that discrepancy at all.

Cheers,
Nick.

>
> >> The 5 year goal was for the Python 3 ecosystem to be a sufficiently
> >> functionally complete alternative to Python 2 for it to be recommended
by
> >> default for every use case where Python 2 wasn't already being used.
> >>
> >> Addressing the key remaining barriers to migration for existing Python
2
> >> users would be an excellent objective to attain before we end upstream
> >> support for Python 2.7, but it's one that would be better addressed by
a
> >> slightly shorter dev cycle than normal for 3.5 than it would be by
> >> falling
> >> into the "just one more feature" trap for Python 3.4.
> >
> > I think a shorter cycle for 3.5 is fine, too.
>
> Great!  I agree with Nick that 6 months is too short, but I would
definitely
> start with betas after 6 months.
>
> Georg
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140108/3b9c4f1b/attachment.html>

From solipsis at pitrou.net  Wed Jan  8 11:16:42 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 08 Jan 2014 11:16:42 +0100
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
 <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
Message-ID: <1389176202.2290.0.camel@fsol>

On mer., 2014-01-08 at 12:06 +1000, Nick Coghlan wrote:
> I'm saying hacking in a complex change in a few weeks when there isn't
> consensus even on the basics of the design just because a few
> moderately high profile developers failed to understand what "5 years
> to be the default choice for new projects" meant would be the height
> of irresponsibility.

Agreed with Nick here. Let's just add a third beta for the clinic churn.

Regards

Antoine.



From eliben at gmail.com  Wed Jan  8 14:48:30 2014
From: eliben at gmail.com (Eli Bendersky)
Date: Wed, 8 Jan 2014 05:48:30 -0800
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <1389176202.2290.0.camel@fsol>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
 <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
 <1389176202.2290.0.camel@fsol>
Message-ID: <CAF-Rda9HXS13hgzrdenSduh88U_sa-vFCxOxzjbtBwTn2ibeXw@mail.gmail.com>

On Wed, Jan 8, 2014 at 2:16 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On mer., 2014-01-08 at 12:06 +1000, Nick Coghlan wrote:
> > I'm saying hacking in a complex change in a few weeks when there isn't
> > consensus even on the basics of the design just because a few
> > moderately high profile developers failed to understand what "5 years
> > to be the default choice for new projects" meant would be the height
> > of irresponsibility.
>
> Agreed with Nick here. Let's just add a third beta for the clinic churn.
>

+1

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140108/34fa58a2/attachment.html>

From barry at python.org  Wed Jan  8 16:01:00 2014
From: barry at python.org (Barry Warsaw)
Date: Wed, 8 Jan 2014 10:01:00 -0500
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CADiSq7drm4L+JZ_u=-VrcScmbU7=wnph3u41u1mR3hVgkbw4fQ@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
 <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
 <52CCB983.5080201@hastings.org>
 <CADiSq7drm4L+JZ_u=-VrcScmbU7=wnph3u41u1mR3hVgkbw4fQ@mail.gmail.com>
Message-ID: <20140108100100.785ecdb4@anarchist.wooz.org>

On Jan 08, 2014, at 05:39 PM, Nick Coghlan wrote:

>I suspect a 6 month cycle would confuse users and inconvenience
>redistributors, but a 12?17 month cycle so 3.5 is published before 2.7
>enters security fix only mode would make a *lot* of sense.

18 months is already the typical development cycle for new versions of Python,
so it would have to be markedly shorter than that.  6-9 months seems about
right, and if we adopted that *and* tightly focused new features in 3.5 to
those that making porting from Python 2 easier, then I could see that as a
reasonable alternative, especially given the realities of the baked-in time
constraints for 3.4.

Adding another beta for clinic churn seems entirely reasonable.

So, let's put "Goals for 3.5" on the agenda for the Language Summit.

-Barry

From g.brandl at gmx.net  Wed Jan  8 19:34:39 2014
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 08 Jan 2014 19:34:39 +0100
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <CADiSq7d0a1BTpuDSCRXVtWbhEB6RKaZWn2=WjqvCVUE4tmF7+Q@mail.gmail.com>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
 <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
 <1389147831.31887.67936897.239242BF@webmail.messagingengine.com>
 <laj4e4$hs9$1@ger.gmane.org>
 <CADiSq7d0a1BTpuDSCRXVtWbhEB6RKaZWn2=WjqvCVUE4tmF7+Q@mail.gmail.com>
Message-ID: <lak5m9$mm5$1@ger.gmane.org>

Am 08.01.2014 11:08, schrieb Nick Coghlan:
> 
> On 8 Jan 2014 17:06, "Georg Brandl" <g.brandl at gmx.net <mailto:g.brandl at gmx.net>>
> wrote:
>>
>> Am 08.01.2014 03:23, schrieb Benjamin Peterson:
>> > On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
>> >> On 8 Jan 2014 08:44, "Eric V. Smith" <eric at trueblade.com
> <mailto:eric at trueblade.com>> wrote:
>> >> >
>> >> > On 1/7/2014 7:33 PM, Benjamin Peterson wrote:
>> >> > > A PyPI module is not so great because you'll have to change every
>> >> > > formatting operation to use a function from a module rather than the %
>> >> > > operator or the format method.
>> >> >
>> >> > I think this is the crux of the issue. Are we trying to say "porting
>> >> > your existing code will be easier", or "change your existing code to
>> >> > this new library, and we'll provide the library on 2.x and 3.y" (for
>> >> > some values of x and y).
>> >> >
>> >> > I think the former is the right way to go, but I also think if we do
>> >> > that we should shoot for 3.4, and this would necessitate a delay in 3.4.
>> >> > Providing this feature for 3.5 might be too late for the target audience
>> >> > of code porters.
>> >>
>> >> I'm saying hacking in a complex change in a few weeks when there isn't
>> >> consensus even on the basics of the design just because a few moderately
>> >> high profile developers failed to understand what "5 years to be the
>> >> default choice for new projects" meant would be the height of
>> >> irresponsibility.
>> >
>> > It's not design from scratch, since it should be fairly close to the 2.x
>> > string formatting mini-languages.
>>
>> Yes, I think the feature set should be settled upon quickly.
> 
> I'm not yet convinced restoring more string-like behaviour to bytes is a better
> solution than a dedicated type specifically for working with ASCII compatible
> wire protocols (that approach is still being kicked around as a possibility in
> the parallel discussion on python-ideas).

Not sure how that is different from converting everything to str and then
converting back after manipulation -- what people want is seamless and efficient
working with the "native" type for sockets, files etc.

But I haven't read up these threads, and I hope a PEP will come out of that as
well.

> One key advantage of such a type is that it could be designed to make "text or
> ASCII bytes" code like the URL parsing as straightforward to write as it was in
> Python 2, whereas adding formatting to bytes objects wouldn't help with that
> discrepancy at all.

Well, even if it works I just hope that wouldn't lead to everyone just using the
new type and leaving bytes to rot.

Georg


From ncoghlan at gmail.com  Thu Jan  9 01:23:23 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 9 Jan 2014 10:23:23 +1000
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <lak5m9$mm5$1@ger.gmane.org>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
 <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
 <1389147831.31887.67936897.239242BF@webmail.messagingengine.com>
 <laj4e4$hs9$1@ger.gmane.org>
 <CADiSq7d0a1BTpuDSCRXVtWbhEB6RKaZWn2=WjqvCVUE4tmF7+Q@mail.gmail.com>
 <lak5m9$mm5$1@ger.gmane.org>
Message-ID: <CADiSq7czaMuK-uS5EOZHQ1O1MsNHH3Gw+9rizONP3z4pTE--1A@mail.gmail.com>

On 9 Jan 2014 02:34, "Georg Brandl" <g.brandl at gmx.net> wrote:
>
> Am 08.01.2014 11:08, schrieb Nick Coghlan:
> >
> > On 8 Jan 2014 17:06, "Georg Brandl" <g.brandl at gmx.net <mailto:
g.brandl at gmx.net>>
> > wrote:
> >>
> >> Am 08.01.2014 03:23, schrieb Benjamin Peterson:
> >> > On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
> >> >> On 8 Jan 2014 08:44, "Eric V. Smith" <eric at trueblade.com
> > <mailto:eric at trueblade.com>> wrote:
> >> >> >
> >> >> > On 1/7/2014 7:33 PM, Benjamin Peterson wrote:
> >> >> > > A PyPI module is not so great because you'll have to change
every
> >> >> > > formatting operation to use a function from a module rather
than the %
> >> >> > > operator or the format method.
> >> >> >
> >> >> > I think this is the crux of the issue. Are we trying to say
"porting
> >> >> > your existing code will be easier", or "change your existing code
to
> >> >> > this new library, and we'll provide the library on 2.x and 3.y"
(for
> >> >> > some values of x and y).
> >> >> >
> >> >> > I think the former is the right way to go, but I also think if we
do
> >> >> > that we should shoot for 3.4, and this would necessitate a delay
in 3.4.
> >> >> > Providing this feature for 3.5 might be too late for the target
audience
> >> >> > of code porters.
> >> >>
> >> >> I'm saying hacking in a complex change in a few weeks when there
isn't
> >> >> consensus even on the basics of the design just because a few
moderately
> >> >> high profile developers failed to understand what "5 years to be the
> >> >> default choice for new projects" meant would be the height of
> >> >> irresponsibility.
> >> >
> >> > It's not design from scratch, since it should be fairly close to the
2.x
> >> > string formatting mini-languages.
> >>
> >> Yes, I think the feature set should be settled upon quickly.
> >
> > I'm not yet convinced restoring more string-like behaviour to bytes is
a better
> > solution than a dedicated type specifically for working with ASCII
compatible
> > wire protocols (that approach is still being kicked around as a
possibility in
> > the parallel discussion on python-ideas).
>
> Not sure how that is different from converting everything to str and then
> converting back after manipulation -- what people want is seamless and
efficient
> working with the "native" type for sockets, files etc.

And that's what I'm saying we *can't* do, because it would put us back in
the position of favouring ASCII compatible binary protocol development over
normal application code. Is network protocol handling an important use
case? Absolutely. However, the core data model needs to continue to push
people strongly towards converting binary data to text or another more
structured format rather than manipulating the raw bytes directly.

I think PEP 460 is a potentially reasonable idea as a way of helping a
couple of specific projects port over, but I also think it's a change that
doesn't actually make it substantially easier to write binary protocol
handling code in Python 3 in general (the impact on urllib.parse is exactly
zero, for example).

There has been a near complete and total lack of experimentation with ways
of making binary protocol development in Python 3 fun and straightforward,
and, as near as I can tell, this has been due to people insisting on only
using the core types, even though we've been suggesting for years that a
new, more specialised type may be needed (perhaps based on memoryview, or
at least the PEP 3118 buffer API).

I can't blame the people doing the conversions for that - not only am I one
of them, but conversions to date have mostly been done based on necessity
(stdlib) or due to user demand (third party libraries and frameworks)
rather than the "just for fun" style of development that leads people to
build the infrastructure they need rather than waiting for someone else to
do it for them.

> But I haven't read up these threads, and I hope a PEP will come out of
that as
> well.

At this point we need experimental code on PyPI that aims to prove that Py3
can be just as fun for binary protocol manipulation *today* far more than
we need proposals to change Python 3.5.

> > One key advantage of such a type is that it could be designed to make
"text or
> > ASCII bytes" code like the URL parsing as straightforward to write as
it was in
> > Python 2, whereas adding formatting to bytes objects wouldn't help with
that
> > discrepancy at all.
>
> Well, even if it works I just hope that wouldn't lead to everyone just
using the
> new type and leaving bytes to rot.

No, because any new type should *only* be used for ASCII compatible binary
protocols. That's an important use case (especially for web protocols), but
still just a subset of the overall space of binary formats.

The folks like Armin Ronacher that are currently complaining are the ones
that really liked having such a type as a builtin and aren't interested in
understanding why we decided it was a seriously problematic default choice.
Since they don't have a vested interest in Python 3 (Python 2 works
perfectly well for binary protocol handling on POSIX systems, and even
Windows for many web use cases, especially for devs that have long ago
mastered the rough edges of the Python 2 model), it's natural that their
reaction is "I will just use Python 2" and "the core developers don't
understand Unicode".

That doesn't make them right, but it *does* mean taking the time to make
sure we fully understand the aspects that are causing pain and explore
genuine alternatives for addressing them, rather than blindly adding back
deeply, deeply error prone constructs that are a frequent source of data
corruption when provided as builtins rather than as advanced tools you only
reach for when you know you need them.

Cheers,
Nick.

>
> Georg
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140109/2e33c691/attachment-0001.html>

From victor.stinner at gmail.com  Thu Jan  9 09:51:22 2014
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 9 Jan 2014 09:51:22 +0100
Subject: [python-committers] Commit right for Vajrasky Kok?
Message-ID: <CAMpsgwYVXuXSqhybmU171YcjzWtgmrQvH8G=diN7po=K3u4ZZw@mail.gmail.com>

Hi,

I noticed that Vajrasky Kok is very active on bugs.python.org. He
produced many patches and contribued to various modules written in
Python and C.

Search "Vajrasky Kok" in the Mercurial history to see how many
contributions he made recently.
On http://bugs.python.org his nickname is "vajrasky".

He knows the process of review and update his patch when he got remarks.

If you consider that he needs a mentor, I can be his mentor.

Victor

From storchaka at gmail.com  Thu Jan  9 15:23:59 2014
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 09 Jan 2014 16:23:59 +0200
Subject: [python-committers] Commit right for Vajrasky Kok?
In-Reply-To: <CAMpsgwYVXuXSqhybmU171YcjzWtgmrQvH8G=diN7po=K3u4ZZw@mail.gmail.com>
References: <CAMpsgwYVXuXSqhybmU171YcjzWtgmrQvH8G=diN7po=K3u4ZZw@mail.gmail.com>
Message-ID: <1642791.96NxDDDZkS@raxxla>

??????, 09-???-2014 09:51:22 Victor Stinner ????????:
> I noticed that Vajrasky Kok is very active on bugs.python.org. He
> produced many patches and contribued to various modules written in
> Python and C.
> 
> Search "Vajrasky Kok" in the Mercurial history to see how many
> contributions he made recently.
> On http://bugs.python.org his nickname is "vajrasky".
> 
> He knows the process of review and update his patch when he got remarks.
> 
> If you consider that he needs a mentor, I can be his mentor.

Vajrasky Kok is good candidate. He is very active and interested in Python 
maintaining, he is respondable. he makes review of others code. But his code 
still not mature. He is often doesn't noticed many details in first versions of 
his patches. He just lacks experience. I believe that a year late he will be 
more experienced.

Perhaps a mentor would help, but every Vajrasky patch, even simplest, should 
be reviewed. And in this case there are no many benefits from commit right 
(except moral encouragement).

Sorry, I'm -0.1 for right now.

From rdmurray at bitdance.com  Thu Jan  9 16:34:18 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 09 Jan 2014 10:34:18 -0500
Subject: [python-committers] Commit right for Vajrasky Kok?
In-Reply-To: <1642791.96NxDDDZkS@raxxla>
References: <CAMpsgwYVXuXSqhybmU171YcjzWtgmrQvH8G=diN7po=K3u4ZZw@mail.gmail.com>
 <1642791.96NxDDDZkS@raxxla>
Message-ID: <20140109153418.7F8A725044D@webabinitio.net>

On Thu, 09 Jan 2014 16:23:59 +0200, Serhiy Storchaka <storchaka at gmail.com> wrote:
> ????????????, 09-??????-2014 09:51:22 Victor Stinner ????????????????:
> > I noticed that Vajrasky Kok is very active on bugs.python.org. He
> > produced many patches and contribued to various modules written in
> > Python and C.
> > 
> > Search "Vajrasky Kok" in the Mercurial history to see how many
> > contributions he made recently.
> > On http://bugs.python.org his nickname is "vajrasky".
> > 
> > He knows the process of review and update his patch when he got remarks.
> > 
> > If you consider that he needs a mentor, I can be his mentor.
> 
> Vajrasky Kok is good candidate. He is very active and interested in Python 
> maintaining, he is respondable. he makes review of others code. But his code 
> still not mature. He is often doesn't noticed many details in first versions of 
> his patches. He just lacks experience. I believe that a year late he will be 
> more experienced.
> 
> Perhaps a mentor would help, but every Vajrasky patch, even simplest, should 
> be reviewed. And in this case there are no many benefits from commit right 
> (except moral encouragement).
> 
> Sorry, I'm -0.1 for right now.

I agree with this assessment.  It might not take a year, but I don't
think the time is quite yet.  Please feel free to encourage him, though.

I feel like he's currently a bit too willing to whip up a patch
to "fix something" without thinking through the consequences and
alternatives...that is, without understanding the problem deeply enough
to be reasonably sure that the fix is the *right* fix.  He's getting
better about that, though.

To put Serhiy's summary another way, we haven't quite reached the point
where it would be easier for us if he could just commit his own patches.

--David

From ncoghlan at gmail.com  Sun Jan 12 16:47:18 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 13 Jan 2014 01:47:18 +1000
Subject: [python-committers] Some topics I have suggested for the language
	summit
Message-ID: <CADiSq7con6uoEP8mVLsRPH0qPt1kqR8Ns7Z=z_7PePp+d=1dbA@mail.gmail.com>

Working across multiple projects has highlighted for me lately how much
unnecessary overhead we're currently dealing with in core development, and
how ineffective we are at delegating responsibility for parts of the docs
that aren't tied directly to the standard library and interpreter
implementation.

In particular, the "core reviewer" model in OpenStack makes substantially
more effective use of core developer time than our core committer model -
if I say a change looks good, it merges cleanly and passes the tests, why
do I need to do the last step manually? (While I don't work on OpenStack, I
work on QA tools for Red Hat. I'm considering deploying Zuul in particular,
since it's at the heart of being able to adopt a core reviewer model).

The other part is that I've suggested we invite the PSF's Outreach &
Education committee to the summit. There are some things we're currently
trying to run entirely from within the existing core dev team (like
maintenance of the tutorial and the howto guides) where that may not be the
most sensible model.

Forwarded to the committers list since there's no reason for these notions
to be secret, but please remember they're just that: notions. Turning them
into reality would require a lot of work, and we'd need to understand how
that was going to happen.

(Given point one above, we probably want some of the PSF infrastructure
team there as well)

Regards,
Nick.
---------- Forwarded message ----------
From: "Nick Coghlan" <ncoghlan at gmail.com>
Date: 13 Jan 2014 01:25
Subject: Re: Two new topics for the language summit
To: "Michael Foord" <fuzzyman at voidspace.org.uk>
Cc:

On a related note - perhaps it would make sense to invite the PSF Outreach
& Education committee?

I'd like to start letting the core team move to a model where we still
ensure the reference docs are up to date, but start handing over more
responsibility for the tutorials and howto guides to folks that are more
focused on education (there will be some overlap, of course, since some
core devs are professional trainers and others may *like* writing
introductory guides).

I'd also like us to consider a more consistent structure like the logging
module now uses (reference, beginner how to guide, advanced how to guide,
cookbook), but there's no way that is feasible in a context where the core
developers are still writing most of the docs.

Unrelated to the above, note that I'm also happy to give an update on the
state of packaging changes. Guido may like to hear what I'm doing with that
authority he delegated to me :)

Cheers,
Nick.
 On 12 Jan 2014 23:47, "Nick Coghlan" <ncoghlan at gmail.com> wrote:

> Docs maintenance and encouraging tech writers to get involved in updating
> docs.python.org
>
> Possible infrastructure updates to improve the core development workflows.
>
> Idea 1: deploy RhodeCode to manage hg.python.org (adds pull request
> support, for example, and makes it easy to create forks and share access
> with non core devs)
>
> Idea 2: finally automate NEWS updates to avoid spurious conflicts
>
> Idea 3: Integrating Zuul (OpenStack merge gating system) with Reitveld,
> RoundUp and BuildBot with the aim of allowing merge gating with our
> existing tools, making it much, much simpler to get trivial changes and
> docs fixes merged (patch review = last manual intervention. From there, if
> the test suite passes on the stable buildbots after merging with the
> relevant branch, it lands automatically)
>
> Cheers,
> Nick.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140113/908ea513/attachment.html>

From tjreedy at udel.edu  Sun Jan 12 21:29:54 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 12 Jan 2014 15:29:54 -0500
Subject: [python-committers] Some topics I have suggested for the
 language summit
In-Reply-To: <CADiSq7con6uoEP8mVLsRPH0qPt1kqR8Ns7Z=z_7PePp+d=1dbA@mail.gmail.com>
References: <CADiSq7con6uoEP8mVLsRPH0qPt1kqR8Ns7Z=z_7PePp+d=1dbA@mail.gmail.com>
Message-ID: <52D2FB42.1080302@udel.edu>

On 1/12/2014 10:47 AM, Nick Coghlan wrote:
> Working across multiple projects has highlighted for me lately how much
> unnecessary overhead we're currently dealing with in core development,
> and how ineffective we are at delegating responsibility for parts of the
> docs that aren't tied directly to the standard library and interpreter
> implementation.

As far as I know, we have not had any problems with people given 
socially restricted commit privileges over-stepping the restrictions. I 
think we should look* for people who would like /Doc/.../*.rst commit 
privileges. Even in the Language and Library, such people could commit 
typo and grammar changes and technical wording changes submitted or 
approves by a code committer.

* As in post a notice to various python lists. There are multiple 
non-committers who have posted articulately to python-list for years. 
Perhaps a couple would be interested if they knew they would be welcome. 
I would be willing to help people to get started (other than with .rst 
markup).

I would note (to candidates) that doc-only commits are easier than 
general commits. Since the doc tools run with installed python, one does 
not have to do the extra setup needed to build Python itself. Simple 
changes that do not involve .rst markup do not need testing. Markup 
changes can be tested on the local machine; there in no need to monitor 
buildbots. If a News entry in needed (and I think not for spelling and 
grammar changes), it goes into separate section with a low rate of entry 
and hence a low rate merge conflicts.

>
> In particular, the "core reviewer" model in OpenStack makes
> substantially more effective use of core developer time than our core
> committer model - if I say a change looks good, it merges cleanly and
> passes the tests, why do I need to do the last step manually? (While I
> don't work on OpenStack, I work on QA tools for Red Hat. I'm considering
> deploying Zuul in particular, since it's at the heart of being able to
> adopt a core reviewer model).
>
> The other part is that I've suggested we invite the PSF's Outreach &
> Education committee to the summit. There are some things we're currently
> trying to run entirely from within the existing core dev team (like
> maintenance of the tutorial and the howto guides) where that may not be
> the most sensible model.


From larry at hastings.org  Mon Jan 13 01:12:38 2014
From: larry at hastings.org (Larry Hastings)
Date: Sun, 12 Jan 2014 16:12:38 -0800
Subject: [python-committers] clinic churn after beta2
In-Reply-To: <1389176202.2290.0.camel@fsol>
References: <CAF-Rda8dH7i1zJEcg4NOMh8ma3jd2DWnjOGYSk645f8tGRkV3w@mail.gmail.com>
 <1389130416.2286.16.camel@fsol>
 <CAF-Rda854Gmxt=FmgqqAY=gNP5Ywt_JdPU6LndzMCnrVunq1uA@mail.gmail.com>
 <20140107231040.GA62752@datlandrewk.home>
 <CADiSq7dwe76KyJkjdXJp8WK0KgG-MC08R5=+F-qFVFiKTXYFUQ@mail.gmail.com>
 <1389141208.23713.67905377.67B8A712@webmail.messagingengine.com>
 <52CC9E37.9090900@trueblade.com>
 <CADiSq7f7FrQoUT84zC8jBLW-pMe03UyjDh8z5pWbj+LwoYw_5w@mail.gmail.com>
 <1389176202.2290.0.camel@fsol>
Message-ID: <52D32F76.7090805@hastings.org>


On 01/08/2014 02:16 AM, Antoine Pitrou wrote:
> Agreed with Nick here. Let's just add a third beta for the clinic churn.

Just to be clear: I plan to add a third beta, and have a proposed 
schedule.  I haven't posted it yet because I'm waiting to hear back from 
the rest of the crew that the schedule will work for them.

Anyway, RC 1 definitely won't be cut on the 18th or released on the 19th.

I'll post here when the slipped schedule is finalized,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140112/b4ab7f30/attachment.html>

From ncoghlan at gmail.com  Mon Jan 13 13:54:27 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 13 Jan 2014 22:54:27 +1000
Subject: [python-committers] Some topics I have suggested for the
	language summit
In-Reply-To: <52D2FB42.1080302@udel.edu>
References: <CADiSq7con6uoEP8mVLsRPH0qPt1kqR8Ns7Z=z_7PePp+d=1dbA@mail.gmail.com>
 <52D2FB42.1080302@udel.edu>
Message-ID: <CADiSq7eYdrQfy_XeWr2SSSrsohf_AHzXMiz8crFvmTsF9s8Rfw@mail.gmail.com>

On 13 January 2014 06:29, Terry Reedy <tjreedy at udel.edu> wrote:
> On 1/12/2014 10:47 AM, Nick Coghlan wrote:
>>
>> Working across multiple projects has highlighted for me lately how much
>> unnecessary overhead we're currently dealing with in core development,
>> and how ineffective we are at delegating responsibility for parts of the
>> docs that aren't tied directly to the standard library and interpreter
>> implementation.
>
>
> As far as I know, we have not had any problems with people given socially
> restricted commit privileges over-stepping the restrictions. I think we
> should look* for people who would like /Doc/.../*.rst commit privileges.
> Even in the Language and Library, such people could commit typo and grammar
> changes and technical wording changes submitted or approves by a code
> committer.
>
> * As in post a notice to various python lists. There are multiple
> non-committers who have posted articulately to python-list for years.
> Perhaps a couple would be interested if they knew they would be welcome. I
> would be willing to help people to get started (other than with .rst
> markup).
>
> I would note (to candidates) that doc-only commits are easier than general
> commits. Since the doc tools run with installed python, one does not have to
> do the extra setup needed to build Python itself. Simple changes that do not
> involve .rst markup do not need testing. Markup changes can be tested on the
> local machine; there in no need to monitor buildbots. If a News entry in
> needed (and I think not for spelling and grammar changes), it goes into
> separate section with a low rate of entry and hence a low rate merge
> conflicts.

Yes, that's exactly the kind of thing I have in mind. However, there
would likely need to be some meta-discussions around structure and
authorial "voice", since that's where we sometimes have conflicts even
today, and at the moment, how those are handled varies a fair bit
depending on who originally authored a piece of text.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From michael at voidspace.org.uk  Mon Jan 13 14:38:27 2014
From: michael at voidspace.org.uk (Michael Foord)
Date: Mon, 13 Jan 2014 13:38:27 +0000
Subject: [python-committers] Some topics I have suggested for the
	language summit
In-Reply-To: <CADiSq7con6uoEP8mVLsRPH0qPt1kqR8Ns7Z=z_7PePp+d=1dbA@mail.gmail.com>
References: <CADiSq7con6uoEP8mVLsRPH0qPt1kqR8Ns7Z=z_7PePp+d=1dbA@mail.gmail.com>
Message-ID: <AACA71D4-3E43-4796-B2E6-E7E0E8A76619@voidspace.org.uk>


On 12 Jan 2014, at 15:47, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Working across multiple projects has highlighted for me lately how much unnecessary overhead we're currently dealing with in core development, and how ineffective we are at delegating responsibility for parts of the docs that aren't tied directly to the standard library and interpreter implementation.
> 
> In particular, the "core reviewer" model in OpenStack makes substantially more effective use of core developer time than our core committer model - if I say a change looks good, it merges cleanly and passes the tests, why do I need to do the last step manually? (While I don't work on OpenStack, I work on QA tools for Red Hat. I'm considering deploying Zuul in particular, since it's at the heart of being able to adopt a core reviewer model).
> 
> The other part is that I've suggested we invite the PSF's Outreach & Education committee to the summit. There are some things we're currently trying to run entirely from within the existing core dev team (like maintenance of the tutorial and the howto guides) where that may not be the most sensible model.


How many people are the Outreach and Education committee? We could cope with another 5-10 people attending. If the committee is less than 20 then we're probably fine inviting them as I doubt all will be able to attend.

All the best,

Michael Foord

> 
> Forwarded to the committers list since there's no reason for these notions to be secret, but please remember they're just that: notions. Turning them into reality would require a lot of work, and we'd need to understand how that was going to happen.
> 
> (Given point one above, we probably want some of the PSF infrastructure team there as well)
> 
> Regards,
> Nick.
> 
> ---------- Forwarded message ----------
> From: "Nick Coghlan" <ncoghlan at gmail.com>
> Date: 13 Jan 2014 01:25
> Subject: Re: Two new topics for the language summit
> To: "Michael Foord" <fuzzyman at voidspace.org.uk>
> Cc: 
> 
> On a related note - perhaps it would make sense to invite the PSF Outreach & Education committee?
> 
> I'd like to start letting the core team move to a model where we still ensure the reference docs are up to date, but start handing over more responsibility for the tutorials and howto guides to folks that are more focused on education (there will be some overlap, of course, since some core devs are professional trainers and others may *like* writing introductory guides).
> 
> I'd also like us to consider a more consistent structure like the logging module now uses (reference, beginner how to guide, advanced how to guide, cookbook), but there's no way that is feasible in a context where the core developers are still writing most of the docs.
> 
> Unrelated to the above, note that I'm also happy to give an update on the state of packaging changes. Guido may like to hear what I'm doing with that authority he delegated to me :)
> 
> Cheers,
> Nick.
> On 12 Jan 2014 23:47, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
> Docs maintenance and encouraging tech writers to get involved in updating docs.python.org  
> 
> Possible infrastructure updates to improve the core development workflows.
> 
> Idea 1: deploy RhodeCode to manage hg.python.org (adds pull request support, for example, and makes it easy to create forks and share access with non core devs)
> 
> Idea 2: finally automate NEWS updates to avoid spurious conflicts
> 
> Idea 3: Integrating Zuul (OpenStack merge gating system) with Reitveld, RoundUp and BuildBot with the aim of allowing merge gating with our existing tools, making it much, much simpler to get trivial changes and docs fixes merged (patch review = last manual intervention. From there, if the test suite passes on the stable buildbots after merging with the relevant branch, it lands automatically)
> 
> Cheers,
> Nick.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html






From ncoghlan at gmail.com  Mon Jan 13 14:59:56 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 13 Jan 2014 23:59:56 +1000
Subject: [python-committers] Some topics I have suggested for the
	language summit
In-Reply-To: <AACA71D4-3E43-4796-B2E6-E7E0E8A76619@voidspace.org.uk>
References: <CADiSq7con6uoEP8mVLsRPH0qPt1kqR8Ns7Z=z_7PePp+d=1dbA@mail.gmail.com>
 <AACA71D4-3E43-4796-B2E6-E7E0E8A76619@voidspace.org.uk>
Message-ID: <CADiSq7cL3UiVgxoz_rbcqDAbiMnR3OAdVtJ4+TV2+__Gd90o5A@mail.gmail.com>

On 13 January 2014 23:38, Michael Foord <michael at voidspace.org.uk> wrote:
>
> On 12 Jan 2014, at 15:47, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> Working across multiple projects has highlighted for me lately how much unnecessary overhead we're currently dealing with in core development, and how ineffective we are at delegating responsibility for parts of the docs that aren't tied directly to the standard library and interpreter implementation.
>>
>> In particular, the "core reviewer" model in OpenStack makes substantially more effective use of core developer time than our core committer model - if I say a change looks good, it merges cleanly and passes the tests, why do I need to do the last step manually? (While I don't work on OpenStack, I work on QA tools for Red Hat. I'm considering deploying Zuul in particular, since it's at the heart of being able to adopt a core reviewer model).
>>
>> The other part is that I've suggested we invite the PSF's Outreach & Education committee to the summit. There are some things we're currently trying to run entirely from within the existing core dev team (like maintenance of the tutorial and the howto guides) where that may not be the most sensible model.
>
> How many people are the Outreach and Education committee? We could cope with another 5-10 people attending. If the committee is less than 20 then we're probably fine inviting them as I doubt all will be able to attend.

To be honest, I don't actually know. However, I was actually thinking
in terms of asking them to send a few interested representatives,
rather than necessarily having them all attend.

Assuming http://www.python.org/psf/committees/#outreach-education-committee-orec
is reasonably up to date, I expect they could come up with a few
volunteers that are going to be in Montreal on the day of the summit
and can spare the time to come chat with us about ways we could work
better together :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From michael at voidspace.org.uk  Mon Jan 13 15:05:07 2014
From: michael at voidspace.org.uk (Michael Foord)
Date: Mon, 13 Jan 2014 14:05:07 +0000
Subject: [python-committers] Some topics I have suggested for the
	language summit
In-Reply-To: <CADiSq7cL3UiVgxoz_rbcqDAbiMnR3OAdVtJ4+TV2+__Gd90o5A@mail.gmail.com>
References: <CADiSq7con6uoEP8mVLsRPH0qPt1kqR8Ns7Z=z_7PePp+d=1dbA@mail.gmail.com>
 <AACA71D4-3E43-4796-B2E6-E7E0E8A76619@voidspace.org.uk>
 <CADiSq7cL3UiVgxoz_rbcqDAbiMnR3OAdVtJ4+TV2+__Gd90o5A@mail.gmail.com>
Message-ID: <6A1DDDA7-7DCF-4DF8-9672-E04022F7E49A@voidspace.org.uk>


On 13 Jan 2014, at 13:59, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 13 January 2014 23:38, Michael Foord <michael at voidspace.org.uk> wrote:
>> 
>> On 12 Jan 2014, at 15:47, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 
>>> Working across multiple projects has highlighted for me lately how much unnecessary overhead we're currently dealing with in core development, and how ineffective we are at delegating responsibility for parts of the docs that aren't tied directly to the standard library and interpreter implementation.
>>> 
>>> In particular, the "core reviewer" model in OpenStack makes substantially more effective use of core developer time than our core committer model - if I say a change looks good, it merges cleanly and passes the tests, why do I need to do the last step manually? (While I don't work on OpenStack, I work on QA tools for Red Hat. I'm considering deploying Zuul in particular, since it's at the heart of being able to adopt a core reviewer model).
>>> 
>>> The other part is that I've suggested we invite the PSF's Outreach & Education committee to the summit. There are some things we're currently trying to run entirely from within the existing core dev team (like maintenance of the tutorial and the howto guides) where that may not be the most sensible model.
>> 
>> How many people are the Outreach and Education committee? We could cope with another 5-10 people attending. If the committee is less than 20 then we're probably fine inviting them as I doubt all will be able to attend.
> 
> To be honest, I don't actually know. However, I was actually thinking
> in terms of asking them to send a few interested representatives,
> rather than necessarily having them all attend.
> 
> Assuming http://www.python.org/psf/committees/#outreach-education-committee-orec
> is reasonably up to date, I expect they could come up with a few
> volunteers that are going to be in Montreal on the day of the summit
> and can spare the time to come chat with us about ways we could work
> better together :)

That sounds fine - are you ok to issue the invite and ask them to let me know who will be attending?

Michael

> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html






From ncoghlan at gmail.com  Mon Jan 13 15:47:31 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 14 Jan 2014 00:47:31 +1000
Subject: [python-committers] Some topics I have suggested for the
	language summit
In-Reply-To: <6A1DDDA7-7DCF-4DF8-9672-E04022F7E49A@voidspace.org.uk>
References: <CADiSq7con6uoEP8mVLsRPH0qPt1kqR8Ns7Z=z_7PePp+d=1dbA@mail.gmail.com>
 <AACA71D4-3E43-4796-B2E6-E7E0E8A76619@voidspace.org.uk>
 <CADiSq7cL3UiVgxoz_rbcqDAbiMnR3OAdVtJ4+TV2+__Gd90o5A@mail.gmail.com>
 <6A1DDDA7-7DCF-4DF8-9672-E04022F7E49A@voidspace.org.uk>
Message-ID: <CADiSq7ePrx60HYUXOCtu1pv=w2BwRnddSEW4H23mAu=m_92h1Q@mail.gmail.com>

On 14 January 2014 00:05, Michael Foord <michael at voidspace.org.uk> wrote:
>> Assuming http://www.python.org/psf/committees/#outreach-education-committee-orec
>> is reasonably up to date, I expect they could come up with a few
>> volunteers that are going to be in Montreal on the day of the summit
>> and can spare the time to come chat with us about ways we could work
>> better together :)
>
> That sounds fine - are you ok to issue the invite and ask them to let me know who will be attending?

Sure, that sounds good. I'll say that we'd like at least a few
representatives to come along to talk about ways we can better combine
efforts, and that we can definitely accommodate 5 people, but to check
with you regarding numbers if more OREC folks will be in Montreal for
the summit day and would like to attend.

Which day is the summit again? April 6th?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From michael at voidspace.org.uk  Wed Jan 15 01:07:19 2014
From: michael at voidspace.org.uk (Michael Foord)
Date: Wed, 15 Jan 2014 00:07:19 +0000
Subject: [python-committers] Some topics I have suggested for the
	language summit
In-Reply-To: <CADiSq7ePrx60HYUXOCtu1pv=w2BwRnddSEW4H23mAu=m_92h1Q@mail.gmail.com>
References: <CADiSq7con6uoEP8mVLsRPH0qPt1kqR8Ns7Z=z_7PePp+d=1dbA@mail.gmail.com>
 <AACA71D4-3E43-4796-B2E6-E7E0E8A76619@voidspace.org.uk>
 <CADiSq7cL3UiVgxoz_rbcqDAbiMnR3OAdVtJ4+TV2+__Gd90o5A@mail.gmail.com>
 <6A1DDDA7-7DCF-4DF8-9672-E04022F7E49A@voidspace.org.uk>
 <CADiSq7ePrx60HYUXOCtu1pv=w2BwRnddSEW4H23mAu=m_92h1Q@mail.gmail.com>
Message-ID: <260CA925-0942-44B3-9EAA-9609298FF2FA@voidspace.org.uk>


On 13 Jan 2014, at 14:47, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 14 January 2014 00:05, Michael Foord <michael at voidspace.org.uk> wrote:
>>> Assuming http://www.python.org/psf/committees/#outreach-education-committee-orec
>>> is reasonably up to date, I expect they could come up with a few
>>> volunteers that are going to be in Montreal on the day of the summit
>>> and can spare the time to come chat with us about ways we could work
>>> better together :)
>> 
>> That sounds fine - are you ok to issue the invite and ask them to let me know who will be attending?
> 
> Sure, that sounds good. I'll say that we'd like at least a few
> representatives to come along to talk about ways we can better combine
> efforts, and that we can definitely accommodate 5 people, but to check
> with you regarding numbers if more OREC folks will be in Montreal for
> the summit day and would like to attend.
> 

Great.

> Which day is the summit again? April 6th?
> 

The 9th!

Michael

> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html






From larry at hastings.org  Wed Jan 15 08:35:56 2014
From: larry at hastings.org (Larry Hastings)
Date: Tue, 14 Jan 2014 23:35:56 -0800
Subject: [python-committers] Updated schedule for Python 3.4
Message-ID: <52D63A5C.102@hastings.org>



We've added a third beta and pushed the whole schedule out by three 
weeks.  Assuming we stick to this schedule, beta 3 will be released Jan 
26th, rc1 Feb 9, rc2 Feb 23, and final March 16th.  That's all the 
details, but here's the release schedule PEP anyway:

    http://www.python.org/dev/peps/pep-0429/


My hope all along has been for 3.4 to ship before the PyCon US sprints 
start on April 14th, so that trunk would be open for 3.5 work.  Right 
now that looks like no problem.

Cheers,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140114/1ed1df28/attachment.html>

From kristjan at ccpgames.com  Thu Jan 16 12:17:49 2014
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Thu, 16 Jan 2014 11:17:49 +0000
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <52D63A5C.102@hastings.org>
References: <52D63A5C.102@hastings.org>
Message-ID: <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>

This is such an obvious question that it probably has been raised before, but anyway:
Why not branch 3.4 earlier than release?  That is how big projects are managed nowadays, you create a staging branch early.
I'd suggest branching it off at b3.  There is no reason to keep all trunk development frozen just because a particular version is in RC mode.
K

From: python-committers [mailto:python-committers-bounces+kristjan=ccpgames.com at python.org] On Behalf Of Larry Hastings
Sent: Wednesday, January 15, 2014 15:36
To: python-committers
Subject: [python-committers] Updated schedule for Python 3.4


My hope all along has been for 3.4 to ship before the PyCon US sprints start on April 14th, so that trunk would be open for 3.5 work.  Right now that looks like no problem.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140116/4d586069/attachment.html>

From doko at ubuntu.com  Thu Jan 16 12:27:17 2014
From: doko at ubuntu.com (Matthias Klose)
Date: Thu, 16 Jan 2014 12:27:17 +0100
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
Message-ID: <52D7C215.1050201@ubuntu.com>

Am 16.01.2014 12:17, schrieb Kristj?n Valur J?nsson:
> This is such an obvious question that it probably has been raised before, but anyway:
> Why not branch 3.4 earlier than release?  That is how big projects are managed nowadays, you create a staging branch early.
> I'd suggest branching it off at b3.  There is no reason to keep all trunk development frozen just because a particular version is in RC mode.

Big projects (like GCC) delay the branching as long as possible and only branch
when the trunk reaches release quality.  Branch maintenance eats developer
resources, and usually opening the trunk for new development distracts
developers from contributing to the release.  I do like the way how this is done
for Python (and GCC).

  Matthias


From kristjan at ccpgames.com  Thu Jan 16 12:38:58 2014
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Thu, 16 Jan 2014 11:38:58 +0000
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <52D7C215.1050201@ubuntu.com>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <52D7C215.1050201@ubuntu.com>
Message-ID: <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>

I suppose different projects have different ways, but I'm actually talking about commercial projects with which I am somewhat familiar.
Once a project goes into feature freeze, it is branched off so that continued feature development can commence, while
Defects are ironed out in the branch.  Bugs obviously get priority.  This also applies to open source, I should think.
Meanwhile, a keen contributor does not have to sit idle waiting for an extended RC phase to play out.

K

-----Original Message-----
From: python-committers [mailto:python-committers-bounces+kristjan=ccpgames.com at python.org] On Behalf Of Matthias Klose
Sent: Thursday, January 16, 2014 19:27
To: python-committers at python.org
Subject: Re: [python-committers] Updated schedule for Python 3.4

Am 16.01.2014 12:17, schrieb Kristj?n Valur J?nsson:
> This is such an obvious question that it probably has been raised before, but anyway:
> Why not branch 3.4 earlier than release?  That is how big projects are managed nowadays, you create a staging branch early.
> I'd suggest branching it off at b3.  There is no reason to keep all trunk development frozen just because a particular version is in RC mode.

Big projects (like GCC) delay the branching as long as possible and only branch when the trunk reaches release quality.  Branch maintenance eats developer resources, and usually opening the trunk for new development distracts developers from contributing to the release.  I do like the way how this is done for Python (and GCC).

  Matthias

_______________________________________________
python-committers mailing list
python-committers at python.org
https://mail.python.org/mailman/listinfo/python-committers



From ncoghlan at gmail.com  Thu Jan 16 13:08:30 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 16 Jan 2014 22:08:30 +1000
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <52D7C215.1050201@ubuntu.com>
 <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>
Message-ID: <CADiSq7dGQnP9VDTCCAaGmFQF80=-qx4JVWXmC9ARXM0i+GqhBA@mail.gmail.com>

On 16 Jan 2014 21:54, "Kristj?n Valur J?nsson" <kristjan at ccpgames.com>
wrote:
>
> I suppose different projects have different ways, but I'm actually
talking about commercial projects with which I am somewhat familiar.
> Once a project goes into feature freeze, it is branched off so that
continued feature development can commence, while
> Defects are ironed out in the branch.  Bugs obviously get priority.  This
also applies to open source, I should think.
> Meanwhile, a keen contributor does not have to sit idle waiting for an
extended RC phase to play out.

It's a social hack to remind people that the current focus is supposed to
be on ironing out issues in the imminent release, with the subsequent
release deliberately deemphasised until the current one is out. (PEP 461 is
a bit of an aberration, since people wanted to ensure we had a solid plan
in place for bringing binary interpolation back for 3.5, and also at least
asked the question about doing so in 3.4)

The commercial world has different ways of dealing with the focus problem,
since there's a more direct relationship between an employer and an
employee than there is between a CPython release manager and other
contributors. For us, though, it's useful to have the state of the branches
reflect current priorities (plus we want to minimise the amount of time we
have two maintenance branches open).

Cheers,
Nick.

>
> K
>
> -----Original Message-----
> From: python-committers [mailto:python-committers-bounces+kristjan=
ccpgames.com at python.org] On Behalf Of Matthias Klose
> Sent: Thursday, January 16, 2014 19:27
> To: python-committers at python.org
> Subject: Re: [python-committers] Updated schedule for Python 3.4
>
> Am 16.01.2014 12:17, schrieb Kristj?n Valur J?nsson:
> > This is such an obvious question that it probably has been raised
before, but anyway:
> > Why not branch 3.4 earlier than release?  That is how big projects are
managed nowadays, you create a staging branch early.
> > I'd suggest branching it off at b3.  There is no reason to keep all
trunk development frozen just because a particular version is in RC mode.
>
> Big projects (like GCC) delay the branching as long as possible and only
branch when the trunk reaches release quality.  Branch maintenance eats
developer resources, and usually opening the trunk for new development
distracts developers from contributing to the release.  I do like the way
how this is done for Python (and GCC).
>
>   Matthias
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140116/a9c90e53/attachment-0001.html>

From martin at v.loewis.de  Thu Jan 16 13:18:36 2014
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 16 Jan 2014 13:18:36 +0100
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <52D7C215.1050201@ubuntu.com>
 <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>
Message-ID: <52D7CE1C.5090809@v.loewis.de>

Am 16.01.14 12:38, schrieb Kristj?n Valur J?nsson:
> I suppose different projects have different ways, but I'm actually talking about commercial projects with which I am somewhat familiar.
> Once a project goes into feature freeze, it is branched off so that continued feature development can commence, while
> Defects are ironed out in the branch.  Bugs obviously get priority.  This also applies to open source, I should think.

I agree with Matthias that it does not (apply):

- "Bugs obviously get priority". They do not, in free software.
  Priority gets instead what contributors like to work on.
- "continued feature development can commence". This is precisely what
  we do not want to happen. Instead, we want to direct attention towards
  bug fixing.

> Meanwhile, a keen contributor does not have to sit idle waiting for
> an extended RC phase to play out.

The hope is that, instead of sitting idle, they actually start working
on bugs, and contributing to finishing the release.

With a DVCS, there is of course an alternative, where one could start
working on new features while the trunk is in feature-freeze.

Regards,
Martin


From g.brandl at gmx.net  Thu Jan 16 14:22:28 2014
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 16 Jan 2014 14:22:28 +0100
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
Message-ID: <lb8mcr$802$1@ger.gmane.org>

Am 16.01.2014 12:17, schrieb Kristj?n Valur J?nsson:
> This is such an obvious question that it probably has been raised before

Oh, only once or twice for every 3.x release so far :)

> but anyway:
> 
> Why not branch 3.4 earlier than release?  That is how big projects are managed
> nowadays, you create a staging branch early.
> 
> I?d suggest branching it off at b3.  There is no reason to keep all trunk
> development frozen just because a particular version is in RC mode.

There's also no reason to not use a personal clone if you want to develop a
new feature.

Georg


From solipsis at pitrou.net  Thu Jan 16 14:47:36 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 16 Jan 2014 14:47:36 +0100
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <lb8mcr$802$1@ger.gmane.org>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <lb8mcr$802$1@ger.gmane.org>
Message-ID: <1389880056.2295.0.camel@fsol>

On jeu., 2014-01-16 at 14:22 +0100, Georg Brandl wrote:
> Am 16.01.2014 12:17, schrieb Kristj?n Valur J?nsson:
> > This is such an obvious question that it probably has been raised before
> 
> Oh, only once or twice for every 3.x release so far :)
> 
> > but anyway:
> > 
> > Why not branch 3.4 earlier than release?  That is how big projects are managed
> > nowadays, you create a staging branch early.
> > 
> > I?d suggest branching it off at b3.  There is no reason to keep all trunk
> > development frozen just because a particular version is in RC mode.
> 
> There's also no reason to not use a personal clone if you want to develop a
> new feature.

The question is less for us than for occasional contributors who see
their patches or feature requests languish on the tracker, and lose
interest.

Regards

Antoine.



From g.brandl at gmx.net  Thu Jan 16 15:03:28 2014
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 16 Jan 2014 15:03:28 +0100
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <1389880056.2295.0.camel@fsol>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <lb8mcr$802$1@ger.gmane.org> <1389880056.2295.0.camel@fsol>
Message-ID: <lb8opn$4t9$1@ger.gmane.org>

Am 16.01.2014 14:47, schrieb Antoine Pitrou:
> On jeu., 2014-01-16 at 14:22 +0100, Georg Brandl wrote:
>> Am 16.01.2014 12:17, schrieb Kristj?n Valur J?nsson:
>> > This is such an obvious question that it probably has been raised before
>> 
>> Oh, only once or twice for every 3.x release so far :)
>> 
>> > but anyway:
>> > 
>> > Why not branch 3.4 earlier than release?  That is how big projects are managed
>> > nowadays, you create a staging branch early.
>> > 
>> > I?d suggest branching it off at b3.  There is no reason to keep all trunk
>> > development frozen just because a particular version is in RC mode.
>> 
>> There's also no reason to not use a personal clone if you want to develop a
>> new feature.
> 
> The question is less for us than for occasional contributors who see
> their patches or feature requests languish on the tracker, and lose
> interest.

To be honest, most patches and feature requests languish much longer than the
beta period, because of lack of manpower and/or interest of a core developer.

And when a core developer gets interested during the beta period, all they need
to do is post "Nice patch/idea, let's discuss and commit it after feature
freeze".  If the contributor is put off by that, well.

Georg


From g.brandl at gmx.net  Thu Jan 16 15:30:18 2014
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 16 Jan 2014 15:30:18 +0100
Subject: [python-committers] 3.3.4 planning
Message-ID: <lb8qc1$q0g$1@ger.gmane.org>

Hi all,

I'm planning to release 3.3.4 candidate 1 together with 3.4 beta 3, i.e. on
the 26th -- and then 3.3.4 final two weeks later if nothing bad comes up.

As always, there will be one more full 3.3 release after 3.4 final, probably
in the May-June timeframe.

cheers,
Georg


From benjamin at python.org  Thu Jan 16 15:31:16 2014
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 16 Jan 2014 06:31:16 -0800
Subject: [python-committers] 3.3.4 planning
In-Reply-To: <lb8qc1$q0g$1@ger.gmane.org>
References: <lb8qc1$q0g$1@ger.gmane.org>
Message-ID: <1389882676.22361.71555521.6044055F@webmail.messagingengine.com>


On Thu, Jan 16, 2014, at 06:30 AM, Georg Brandl wrote:
> Hi all,
> 
> I'm planning to release 3.3.4 candidate 1 together with 3.4 beta 3, i.e.
> on
> the 26th -- and then 3.3.4 final two weeks later if nothing bad comes up.
> 
> As always, there will be one more full 3.3 release after 3.4 final,
> probably
> in the May-June timeframe.

Also, for those curious, this is when the 3.1 line will come to a
screeching halt.


From kristjan at ccpgames.com  Thu Jan 16 16:02:10 2014
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Thu, 16 Jan 2014 15:02:10 +0000
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <52D7CE1C.5090809@v.loewis.de>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <52D7C215.1050201@ubuntu.com>
 <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>
 <52D7CE1C.5090809@v.loewis.de>
Message-ID: <EFE3877620384242A686D52278B7CCD3A5246E03@rkv-it-exch103>

The hope is that by not adding features to 2.x, people will flock around 3.x en masse :)
K

-----Original Message-----
From: "Martin v. L?wis" [mailto:martin at v.loewis.de] 
Sent: 16. jan?ar 2014 20:19
To: Kristj?n Valur J?nsson; Matthias Klose; python-committers at python.org
Subject: Re: [python-committers] Updated schedule for Python 3.4

The hope is that, instead of sitting idle, they actually start working on bugs, and contributing to finishing the release.




From storchaka at gmail.com  Thu Jan 16 18:19:30 2014
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 16 Jan 2014 19:19:30 +0200
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <lb8opn$4t9$1@ger.gmane.org>
References: <52D63A5C.102@hastings.org> <1389880056.2295.0.camel@fsol>
 <lb8opn$4t9$1@ger.gmane.org>
Message-ID: <1555507.5A0veQudau@raxxla>

??????, 16-???-2014 15:03:28 Georg Brandl ????????:
> Am 16.01.2014 14:47, schrieb Antoine Pitrou:
> > The question is less for us than for occasional contributors who see
> > their patches or feature requests languish on the tracker, and lose
> > interest.
> 
> To be honest, most patches and feature requests languish much longer than
> the beta period, because of lack of manpower and/or interest of a core
> developer.
> 
> And when a core developer gets interested during the beta period, all they
> need to do is post "Nice patch/idea, let's discuss and commit it after
> feature freeze".  If the contributor is put off by that, well.

There are several ready or almost ready patches which did not have time to 
jump on the train. E.g. C implementation of lru_cache or Kristj?n's nice 
enchancement for HTTPResponse (this is only my fault, I just forgot about this 
patch).

And some my patches wait for review longer than year.

From ncoghlan at gmail.com  Fri Jan 17 00:51:02 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 17 Jan 2014 09:51:02 +1000
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <EFE3877620384242A686D52278B7CCD3A5246E03@rkv-it-exch103>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <52D7C215.1050201@ubuntu.com>
 <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>
 <52D7CE1C.5090809@v.loewis.de>
 <EFE3877620384242A686D52278B7CCD3A5246E03@rkv-it-exch103>
Message-ID: <CADiSq7fCh1p4-3Y6yFaLy=N5KjekZmD+_w37y9M+ax1u1GmoQw@mail.gmail.com>

On 17 Jan 2014 01:02, "Kristj?n Valur J?nsson" <kristjan at ccpgames.com>
wrote:
>
> The hope is that by not adding features to 2.x, people will flock around
3.x en masse :)

Very few of us think that way - it's that we think Python 3 is a better
language in most ways, and it is certainly much easier and more pleasant to
work on, which matters a great deal for something many of us are doing as a
side project outside work hours. I personally get very annoyed by snide
remarks like this suggesting that four years of parallel feature
development and eight years of parallel maintenance on a volunteer driven
project *aren't enough*.

Would you have preferred a Gnome or KDE style transition where the parallel
development periods were measured in months rather than years?

Open source projects are innately engineering driven, and thus vastly less
tolerant of long term technical debt than commercial enterprises that can
offer additional financial incentives to tolerate working with old code for
backwards compatibility reasons. That's *why* a company like Red Hat can
continue to support Python 2.7 out to 2023+, even though upstream community
support will end in 2015 - people don't maintain and support old platforms
like RHEL3 for fun, we do it because we get *paid*.

CCP could have stepped in at any time and proposed funding (or organising
funding for) a full Python 2.8 release after it became clear that
python-dev wasn't going to do it voluntarily, but they, like every other
commercial entity, realised doing so was likely not to be cost effective
given the preferences of upstream and the extended life cycle of 2.7. It
sounds like they may be changing their mind as 2015 nears and the idea of
Stackless 2.8 is considered, but that's exactly the way open source
*should* work.

Regards,
Nick.

> K
>
> -----Original Message-----
> From: "Martin v. L?wis" [mailto:martin at v.loewis.de]
> Sent: 16. jan?ar 2014 20:19
> To: Kristj?n Valur J?nsson; Matthias Klose; python-committers at python.org
> Subject: Re: [python-committers] Updated schedule for Python 3.4
>
> The hope is that, instead of sitting idle, they actually start working on
bugs, and contributing to finishing the release.
>
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140117/2e5911f2/attachment.html>

From ncoghlan at gmail.com  Fri Jan 17 00:57:29 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 17 Jan 2014 09:57:29 +1000
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <1555507.5A0veQudau@raxxla>
References: <52D63A5C.102@hastings.org> <1389880056.2295.0.camel@fsol>
 <lb8opn$4t9$1@ger.gmane.org> <1555507.5A0veQudau@raxxla>
Message-ID: <CADiSq7cD9Qo02rmst5MsrcgUssQidm94tWykvvqWa0PjvjTY2w@mail.gmail.com>

On 17 Jan 2014 03:25, "Serhiy Storchaka" <storchaka at gmail.com> wrote:
>
> ??????, 16-???-2014 15:03:28 Georg Brandl ????????:
> > Am 16.01.2014 14:47, schrieb Antoine Pitrou:
> > > The question is less for us than for occasional contributors who see
> > > their patches or feature requests languish on the tracker, and lose
> > > interest.
> >
> > To be honest, most patches and feature requests languish much longer
than
> > the beta period, because of lack of manpower and/or interest of a core
> > developer.
> >
> > And when a core developer gets interested during the beta period, all
they
> > need to do is post "Nice patch/idea, let's discuss and commit it after
> > feature freeze".  If the contributor is put off by that, well.
>
> There are several ready or almost ready patches which did not have time to
> jump on the train. E.g. C implementation of lru_cache or Kristj?n's nice
> enchancement for HTTPResponse (this is only my fault, I just forgot about
this
> patch).
>
> And some my patches wait for review longer than year.

I think a lot of this delay can be removed by adjusting the tooling to make
more effective use of core developer time. That's why I have a few tooling
discussions on the language summit agenda, primarily the idea of using
RhodeCode to power hg.python.org and figuring out how to integrate Zuul
with Reitveld, RoundUp, BuildBot and Mercurial to attain an OpenStack style
merge gating system where every merge step after a positive review in
Reitveld is fully automated.

Cheers,
Nick.

> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140117/2f5574f7/attachment.html>

From kristjan at ccpgames.com  Fri Jan 17 03:03:21 2014
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Fri, 17 Jan 2014 02:03:21 +0000
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <CADiSq7fCh1p4-3Y6yFaLy=N5KjekZmD+_w37y9M+ax1u1GmoQw@mail.gmail.com>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <52D7C215.1050201@ubuntu.com>
 <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>
 <52D7CE1C.5090809@v.loewis.de>
 <EFE3877620384242A686D52278B7CCD3A5246E03@rkv-it-exch103>
 <CADiSq7fCh1p4-3Y6yFaLy=N5KjekZmD+_w37y9M+ax1u1GmoQw@mail.gmail.com>
Message-ID: <EFE3877620384242A686D52278B7CCD3A5247708@rkv-it-exch103>

I never got the impression that this was a matter of funding, Nick.
And while I completely understand that core developers enjoy working in 3 much more, it was decided to not accept any improvements for a +2.7 version even from those that would do so voluntarily.  This could have be done without making any commitment to release a 2.8 at any point.
This is why I drew the comparison.  There are barriers put in place to try to achieve a social engineering result.

K

From: Nick Coghlan [mailto:ncoghlan at gmail.com]
Sent: Friday, January 17, 2014 7:51
To: Kristj?n Valur J?nsson
Cc: Matthias Klose; python-committers; Martin v. L?wis
Subject: Re: [python-committers] Updated schedule for Python 3.4


On 17 Jan 2014 01:02, "Kristj?n Valur J?nsson" <kristjan at ccpgames.com<mailto:kristjan at ccpgames.com>> wrote:
>
> The hope is that by not adding features to 2.x, people will flock around 3.x en masse :)

Very few of us think that way - it's that we think Python 3 is a better language in most ways, and it is certainly much easier and more pleasant to work on, which matters a great deal for something many of us are doing as a side project outside work hours. I personally get very annoyed by snide remarks like this suggesting that four years of parallel feature development and eight years of parallel maintenance on a volunteer driven project *aren't enough*.

Would you have preferred a Gnome or KDE style transition where the parallel development periods were measured in months rather than years?

Open source projects are innately engineering driven, and thus vastly less tolerant of long term technical debt than commercial enterprises that can offer additional financial incentives to tolerate working with old code for backwards compatibility reasons. That's *why* a company like Red Hat can continue to support Python 2.7 out to 2023+, even though upstream community support will end in 2015 - people don't maintain and support old platforms like RHEL3 for fun, we do it because we get *paid*.

CCP could have stepped in at any time and proposed funding (or organising funding for) a full Python 2.8 release after it became clear that python-dev wasn't going to do it voluntarily, but they, like every other commercial entity, realised doing so was likely not to be cost effective given the preferences of upstream and the extended life cycle of 2.7. It sounds like they may be changing their mind as 2015 nears and the idea of Stackless 2.8 is considered, but that's exactly the way open source *should* work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140117/d3e523ea/attachment-0001.html>

From benjamin at python.org  Fri Jan 17 06:34:02 2014
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 16 Jan 2014 21:34:02 -0800
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <EFE3877620384242A686D52278B7CCD3A5247708@rkv-it-exch103>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <52D7C215.1050201@ubuntu.com>
 <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>
 <52D7CE1C.5090809@v.loewis.de>
 <EFE3877620384242A686D52278B7CCD3A5246E03@rkv-it-exch103>
 <CADiSq7fCh1p4-3Y6yFaLy=N5KjekZmD+_w37y9M+ax1u1GmoQw@mail.gmail.com>
 <EFE3877620384242A686D52278B7CCD3A5247708@rkv-it-exch103>
Message-ID: <1389936842.9492.71861949.52E55AE4@webmail.messagingengine.com>

On Thu, Jan 16, 2014, at 06:03 PM, Kristj?n Valur J?nsson wrote:
> I never got the impression that this was a matter of funding, Nick.
> And while I completely understand that core developers enjoy working in 3
> much more, it was decided to not accept any improvements for a +2.7
> version even from those that would do so voluntarily.  This could have be
> done without making any commitment to release a 2.8 at any point.
> This is why I drew the comparison.  There are barriers put in place to
> try to achieve a social engineering result.

It's not a matter of simply accepting any improvements for 2.7 even from
volunteers. If 2.8 happened, among other things people would have to
- make releases (building installers, etc)
- review new features
- triage bugs
- fix bugs in new features
- maintain yet another branch

It would surely add overhead for everyone.

From g.brandl at gmx.net  Fri Jan 17 06:42:25 2014
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 17 Jan 2014 06:42:25 +0100
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <CADiSq7cD9Qo02rmst5MsrcgUssQidm94tWykvvqWa0PjvjTY2w@mail.gmail.com>
References: <52D63A5C.102@hastings.org> <1389880056.2295.0.camel@fsol>
 <lb8opn$4t9$1@ger.gmane.org> <1555507.5A0veQudau@raxxla>
 <CADiSq7cD9Qo02rmst5MsrcgUssQidm94tWykvvqWa0PjvjTY2w@mail.gmail.com>
Message-ID: <lbafq7$vcr$1@ger.gmane.org>

Am 17.01.2014 00:57, schrieb Nick Coghlan:
> 
> On 17 Jan 2014 03:25, "Serhiy Storchaka" <storchaka at gmail.com
> <mailto:storchaka at gmail.com>> wrote:
>>
>> ??????, 16-???-2014 15:03:28 Georg Brandl ????????:
>> > Am 16.01.2014 14:47, schrieb Antoine Pitrou:
>> > > The question is less for us than for occasional contributors who see
>> > > their patches or feature requests languish on the tracker, and lose
>> > > interest.
>> >
>> > To be honest, most patches and feature requests languish much longer than
>> > the beta period, because of lack of manpower and/or interest of a core
>> > developer.
>> >
>> > And when a core developer gets interested during the beta period, all they
>> > need to do is post "Nice patch/idea, let's discuss and commit it after
>> > feature freeze".  If the contributor is put off by that, well.
>>
>> There are several ready or almost ready patches which did not have time to
>> jump on the train. E.g. C implementation of lru_cache or Kristj?n's nice
>> enchancement for HTTPResponse (this is only my fault, I just forgot about this
>> patch).
>>
>> And some my patches wait for review longer than year.
> 
> I think a lot of this delay can be removed by adjusting the tooling to make more
> effective use of core developer time. That's why I have a few tooling
> discussions on the language summit agenda, primarily the idea of using RhodeCode
> to power hg.python.org <http://hg.python.org> and figuring out how to integrate
> Zuul with Reitveld, RoundUp, BuildBot and Mercurial to attain an OpenStack style
> merge gating system where every merge step after a positive review in Reitveld
> is fully automated.

If Zuul is in any way similar to Gerrit, I think that would be very, very
useful indeed for attacking this delay.

Georg


From g.brandl at gmx.net  Fri Jan 17 06:44:28 2014
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 17 Jan 2014 06:44:28 +0100
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <1389936842.9492.71861949.52E55AE4@webmail.messagingengine.com>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <52D7C215.1050201@ubuntu.com>
 <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>
 <52D7CE1C.5090809@v.loewis.de>
 <EFE3877620384242A686D52278B7CCD3A5246E03@rkv-it-exch103>
 <CADiSq7fCh1p4-3Y6yFaLy=N5KjekZmD+_w37y9M+ax1u1GmoQw@mail.gmail.com>
 <EFE3877620384242A686D52278B7CCD3A5247708@rkv-it-exch103>
 <1389936842.9492.71861949.52E55AE4@webmail.messagingengine.com>
Message-ID: <lbafu2$17f$1@ger.gmane.org>

Am 17.01.2014 06:34, schrieb Benjamin Peterson:
> On Thu, Jan 16, 2014, at 06:03 PM, Kristj?n Valur J?nsson wrote:
>> I never got the impression that this was a matter of funding, Nick.
>> And while I completely understand that core developers enjoy working in 3
>> much more, it was decided to not accept any improvements for a +2.7
>> version even from those that would do so voluntarily.  This could have be
>> done without making any commitment to release a 2.8 at any point.
>> This is why I drew the comparison.  There are barriers put in place to
>> try to achieve a social engineering result.
> 
> It's not a matter of simply accepting any improvements for 2.7 even from
> volunteers. If 2.8 happened, among other things people would have to
> - make releases (building installers, etc)
> - review new features
> - triage bugs
> - fix bugs in new features
> - maintain yet another branch
> 
> It would surely add overhead for everyone.

Especially since "accept improvements" means making sure the end product is
of the same quality as 2.7 was.

Georg


From ethan at stoneleaf.us  Fri Jan 17 05:57:53 2014
From: ethan at stoneleaf.us (Ethan Furman)
Date: Thu, 16 Jan 2014 20:57:53 -0800
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <EFE3877620384242A686D52278B7CCD3A5247708@rkv-it-exch103>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <52D7C215.1050201@ubuntu.com>
 <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>
 <52D7CE1C.5090809@v.loewis.de>
 <EFE3877620384242A686D52278B7CCD3A5246E03@rkv-it-exch103>
 <CADiSq7fCh1p4-3Y6yFaLy=N5KjekZmD+_w37y9M+ax1u1GmoQw@mail.gmail.com>
 <EFE3877620384242A686D52278B7CCD3A5247708@rkv-it-exch103>
Message-ID: <52D8B851.8000407@stoneleaf.us>

On 01/16/2014 06:03 PM, ? wrote:
>
> And while I completely understand that core developers enjoy working in 3 much more, it was decided to not accept any
> improvements for a +2.7 version [...]

You mean, like, new features?  Have any new features been put in 2.7 after it hit feature freeze?

--
~Ethan~

From ncoghlan at gmail.com  Fri Jan 17 12:27:31 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 17 Jan 2014 21:27:31 +1000
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <EFE3877620384242A686D52278B7CCD3A5247708@rkv-it-exch103>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <52D7C215.1050201@ubuntu.com>
 <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>
 <52D7CE1C.5090809@v.loewis.de>
 <EFE3877620384242A686D52278B7CCD3A5246E03@rkv-it-exch103>
 <CADiSq7fCh1p4-3Y6yFaLy=N5KjekZmD+_w37y9M+ax1u1GmoQw@mail.gmail.com>
 <EFE3877620384242A686D52278B7CCD3A5247708@rkv-it-exch103>
Message-ID: <CADiSq7fgZ9ydbwNHHTVkm6t8+y-HyE6jFoLi1AYpmXnPDmv8Nw@mail.gmail.com>

On 17 Jan 2014 12:03, "Kristj?n Valur J?nsson" <kristjan at ccpgames.com>
wrote:
>
> I never got the impression that this was a matter of funding, Nick.
>
> And while I completely understand that core developers enjoy working in 3
much more, it was decided to not accept any improvements for a +2.7 version
even from those that would do so voluntarily.  This could have be done
without making any commitment to release a 2.8 at any point.

Doing that on the core infrastructure requires core developer *time* in
order to review the patches. We made it crystal clear we weren't interested
in providing that for free, and nobody ever even asked about the
possibility of *paid* development to create a Python 2.8.

> This is why I drew the comparison.  There are barriers put in place to
try to achieve a social engineering result.

The only barrier was the core development team deciding not to proceed with
2.x feature development for free any more after the parallel 2.6 and 2.7
releases. The question of paid development has never been discussed. It's
only come up now because we're almost two releases into Python 3 only
development and commercial Python 2 users are realising there is stuff
there that they want that is technically backwards compatible with Python 2.

That means that anyone that wants a Python 2.8 release either needs to fund
the development infrastructure for a fork that doesn't involve the existing
core development team, or else come to a deal with enough core developers
that Guido can be persuaded to approve a "bought & paid for" 2.8 release.

However, given the fact that most interesting backwards compatible changes
can already be backported via PyPI, it's highly unlikely that anyone will
put up that kind of money. Stackless 2.8 is the sole exception because you
*already* have the infrastructure and community in place to maintain a
CPython 2 fork, so backporting a few additional changes from CPython 3
really doesn't make a big difference to that workload.

Cheers,
Nick.

>
>
>
> K
>
>
>
> From: Nick Coghlan [mailto:ncoghlan at gmail.com]
> Sent: Friday, January 17, 2014 7:51
> To: Kristj?n Valur J?nsson
> Cc: Matthias Klose; python-committers; Martin v. L?wis
>
> Subject: Re: [python-committers] Updated schedule for Python 3.4
>
>
>
>
> On 17 Jan 2014 01:02, "Kristj?n Valur J?nsson" <kristjan at ccpgames.com>
wrote:
> >
> > The hope is that by not adding features to 2.x, people will flock
around 3.x en masse :)
>
> Very few of us think that way - it's that we think Python 3 is a better
language in most ways, and it is certainly much easier and more pleasant to
work on, which matters a great deal for something many of us are doing as a
side project outside work hours. I personally get very annoyed by snide
remarks like this suggesting that four years of parallel feature
development and eight years of parallel maintenance on a volunteer driven
project *aren't enough*.
>
> Would you have preferred a Gnome or KDE style transition where the
parallel development periods were measured in months rather than years?
>
> Open source projects are innately engineering driven, and thus vastly
less tolerant of long term technical debt than commercial enterprises that
can offer additional financial incentives to tolerate working with old code
for backwards compatibility reasons. That's *why* a company like Red Hat
can continue to support Python 2.7 out to 2023+, even though upstream
community support will end in 2015 - people don't maintain and support old
platforms like RHEL3 for fun, we do it because we get *paid*.
>
> CCP could have stepped in at any time and proposed funding (or organising
funding for) a full Python 2.8 release after it became clear that
python-dev wasn't going to do it voluntarily, but they, like every other
commercial entity, realised doing so was likely not to be cost effective
given the preferences of upstream and the extended life cycle of 2.7. It
sounds like they may be changing their mind as 2015 nears and the idea of
Stackless 2.8 is considered, but that's exactly the way open source
*should* work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140117/88580e15/attachment.html>

From tjreedy at udel.edu  Fri Jan 17 20:53:38 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 17 Jan 2014 14:53:38 -0500
Subject: [python-committers] Updated schedule for Python 3.4
In-Reply-To: <CADiSq7fgZ9ydbwNHHTVkm6t8+y-HyE6jFoLi1AYpmXnPDmv8Nw@mail.gmail.com>
References: <52D63A5C.102@hastings.org>
 <EFE3877620384242A686D52278B7CCD3A5246ADF@rkv-it-exch103>
 <52D7C215.1050201@ubuntu.com>
 <EFE3877620384242A686D52278B7CCD3A5246B62@rkv-it-exch103>
 <52D7CE1C.5090809@v.loewis.de>
 <EFE3877620384242A686D52278B7CCD3A5246E03@rkv-it-exch103>
 <CADiSq7fCh1p4-3Y6yFaLy=N5KjekZmD+_w37y9M+ax1u1GmoQw@mail.gmail.com>
 <EFE3877620384242A686D52278B7CCD3A5247708@rkv-it-exch103>
 <CADiSq7fgZ9ydbwNHHTVkm6t8+y-HyE6jFoLi1AYpmXnPDmv8Nw@mail.gmail.com>
Message-ID: <52D98A42.5090000@udel.edu>

On 1/17/2014 6:27 AM, Nick Coghlan wrote:
>
> On 17 Jan 2014 12:03, "Kristj?n Valur J?nsson" <kristjan at ccpgames.com
> <mailto:kristjan at ccpgames.com>> wrote:
> > And while I completely understand that core developers enjoy working
> > in 3 much more, it was decided to not accept any improvements for a +2.7
> > version even from those that would do so voluntarily.  This could have
> > be done without making any commitment to release a 2.8 at any point.

At least some of us would have loved to have someone dedicated to 
developing 2.7-only patches, backporting 3.3 (currently) maintenance 
patches to 2.7, and watching 2.7 buildbots after either type were 
pushed. No one ever volunteered.

Guido has suggested that our future 2.7 work focus on keeping 2.7 
building on the latest OSes rather than on bugfixes per se. For either 
goal, volunteers (whether paid by someone else or not) would still be 
helpful.

> Doing that on the core infrastructure requires core developer *time* in
> order to review the patches.

Indeed, we need to become more efficient just to adequately support 3.x.

--
Terry Jan Reedy



From ncoghlan at gmail.com  Sun Jan 19 06:34:55 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 19 Jan 2014 15:34:55 +1000
Subject: [python-committers] LCA2014 presentation on Zuul,
	OpenStack's merge gating system
Message-ID: <CADiSq7ejLD=SxoTp_h=mGJO+t5fvOW1QDoq69Z77=PsbmZE_Bw@mail.gmail.com>

One of the items I have on the language summit agenda is the core
reviewer workflow used by the OpenStack project, specifically Zuul,
the merge gating system that powers that workflow. I know some other
folks here are working on OpenStack these days so this will already be
familiar to them, but many aren't. I'm not either, but my day job
involves developing CI workflow automation tools for Red Hat, so I'm
paying very close attention to what the OpenStack infrastructure team
are up to.

We don't necessarily have to wait until the language summit to discuss
it though, so I figured I'd pass along a link to James Blair's
presentation at linux.conf.au 2014:

Stream: https://www.youtube.com/watch?v=sLD9LHc1QFM
Download: http://mirror.linux.org.au/linux.conf.au/2014/Friday/106-How_OpenStack_Improves_Code_Quality_with_Project_Gating_and_Zuul_-_James_Blair.mp4

The Zuul docs are at: http://ci.openstack.org/zuul/
The OpenStack Zuul dashboard is at: http://status.openstack.org/zuul/

The key difference, relative to our current workflow, is to take the
human out of the loop for the final pre-merge test run. Instead, once
a core reviewer gives a patch a +2, the process of taking that
reviewed patch, checking it still merges correctly, checking it passes
all the tests on the stable buildbots and then merging it into source
control would all be handled automatically by Zuul.

This will require and/or enable eliminating several of the current
annoyances in the core development workflow:

- the annoyingly manual "download patch, apply patch, run tests
locally, commit change, push change, watch the buildbots for problems"
approach goes away entirely (while what we have now is substantially
better than what we had a few years ago, times move on and projects
like OpenStack raise the bar when it comes to figuring out how to make
the most effective of scarce contributor time)
- spurious conflicts on NEWS will go away (as we'll have to finally
address this in order to avoid breaking Zuul's gating)
- push races will go away (since merging would now be handled by Zuul,
non conflicting changes would be rebased automatically, and only
conflicting changes would be bounced back to the submitter for
updates). Critically, conference sprints might create a backlog in
Zuul, but they wouldn't completely break a developer's workflow
through incessant push races relating to non-conflicting changes.
- POSIX developers breaking the Windows buildbots and vice-versa
(since Zuul would ensure at least the stable buildbots remain green by
blocking such changes before they hit the main branches). This means
even when we get such things wrong, we will no longer have the time
pressure of needing to unbreak other people's builds.
- approving and merging pure docs patches should become largely
trivial, as it should be possible to configure Zuul to only check that
the docs build cleanly for those, rather than running the full test
suite across all the stable buildbots.
- checking for a contributor licensing agreement in Roundup before
processing a patch could also be automated, rather than requiring core
developers to check for it manually.

Zuul, as OpenStack use it, already has plugins for the Gerrit code
review/git repo management system (at least as customised by the
OpenStack infrastructure folks), as well as for Jenkins to run the
automated CI tests.

Rather than suggesting wholesale changes to our own infrastructure,
what I am suggesting we consider is devoting time (and potentially PSF
funding) to getting Zuul to play nice with Roundup, Reitveld, BuildBot
and Mercurial. (Like the rest of our existing infrastructure, Zuul is
a web service implemented in Python).

The main technical challenges I foresee are:

* dealing with maintenance branches (especially for patches which
don't merge forward cleanly), since OpenStack currently appear to
"handle" that limitation by just not providing upstream maintenance
branches at all, leaving downstream vendors to fill the gap
* finally cleaning up the way we manage the NEWS file (see
http://bugs.python.org/issue18967 for discussion)
* replicating Gerrit's patch approval/voting mechanism in Reitveld
* replicating Gerrit's merge/rebase capabilities in Mercurial (I'm
sure Mercurial is functionally capable of this, I just don't know the
best way to model it).
* actually writing the new Zuul plugins to talk to the services used
by the CPython project, rather than those used by OpenStack

There would also be a non-trivial update to the developer guide
involved in such a change, since it would heavily impact the core
developer workflows, as well as the way external contributors interact
with the core development team.

If people find this idea interesting, I would like to invite some of
the Mercurial devs and OpenStack infrastructure folks (i.e. Zuul devs)
to the language summit (leaving it up to them if they stay for the
whole day, or just this part). I believe we already have enough
Reitveld, Roundup and Buildbot experience amongst the core development
team to assess the feasibility of the idea from that side of things.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From alex.gaynor at gmail.com  Sun Jan 19 06:37:38 2014
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Sat, 18 Jan 2014 23:37:38 -0600
Subject: [python-committers] LCA2014 presentation on Zuul,
 OpenStack's merge gating system
In-Reply-To: <CADiSq7ejLD=SxoTp_h=mGJO+t5fvOW1QDoq69Z77=PsbmZE_Bw@mail.gmail.com>
References: <CADiSq7ejLD=SxoTp_h=mGJO+t5fvOW1QDoq69Z77=PsbmZE_Bw@mail.gmail.com>
Message-ID: <CAFRnB2VSeQ5Cy8ZDbp_Qs3z9Wa72tG8uje=8OOESqmCu2sbpxg@mail.gmail.com>

While I'm not a particularly active python-developer, I have spent quite a
bit of time using OpenStack's Zuul/gerrit system/workflow and all I can say
is it: It is the right way to write software. Huge +1 from me on every
project using it :-)

Alex


On Sat, Jan 18, 2014 at 11:34 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> One of the items I have on the language summit agenda is the core
> reviewer workflow used by the OpenStack project, specifically Zuul,
> the merge gating system that powers that workflow. I know some other
> folks here are working on OpenStack these days so this will already be
> familiar to them, but many aren't. I'm not either, but my day job
> involves developing CI workflow automation tools for Red Hat, so I'm
> paying very close attention to what the OpenStack infrastructure team
> are up to.
>
> We don't necessarily have to wait until the language summit to discuss
> it though, so I figured I'd pass along a link to James Blair's
> presentation at linux.conf.au 2014:
>
> Stream: https://www.youtube.com/watch?v=sLD9LHc1QFM
> Download:
> http://mirror.linux.org.au/linux.conf.au/2014/Friday/106-How_OpenStack_Improves_Code_Quality_with_Project_Gating_and_Zuul_-_James_Blair.mp4
>
> The Zuul docs are at: http://ci.openstack.org/zuul/
> The OpenStack Zuul dashboard is at: http://status.openstack.org/zuul/
>
> The key difference, relative to our current workflow, is to take the
> human out of the loop for the final pre-merge test run. Instead, once
> a core reviewer gives a patch a +2, the process of taking that
> reviewed patch, checking it still merges correctly, checking it passes
> all the tests on the stable buildbots and then merging it into source
> control would all be handled automatically by Zuul.
>
> This will require and/or enable eliminating several of the current
> annoyances in the core development workflow:
>
> - the annoyingly manual "download patch, apply patch, run tests
> locally, commit change, push change, watch the buildbots for problems"
> approach goes away entirely (while what we have now is substantially
> better than what we had a few years ago, times move on and projects
> like OpenStack raise the bar when it comes to figuring out how to make
> the most effective of scarce contributor time)
> - spurious conflicts on NEWS will go away (as we'll have to finally
> address this in order to avoid breaking Zuul's gating)
> - push races will go away (since merging would now be handled by Zuul,
> non conflicting changes would be rebased automatically, and only
> conflicting changes would be bounced back to the submitter for
> updates). Critically, conference sprints might create a backlog in
> Zuul, but they wouldn't completely break a developer's workflow
> through incessant push races relating to non-conflicting changes.
> - POSIX developers breaking the Windows buildbots and vice-versa
> (since Zuul would ensure at least the stable buildbots remain green by
> blocking such changes before they hit the main branches). This means
> even when we get such things wrong, we will no longer have the time
> pressure of needing to unbreak other people's builds.
> - approving and merging pure docs patches should become largely
> trivial, as it should be possible to configure Zuul to only check that
> the docs build cleanly for those, rather than running the full test
> suite across all the stable buildbots.
> - checking for a contributor licensing agreement in Roundup before
> processing a patch could also be automated, rather than requiring core
> developers to check for it manually.
>
> Zuul, as OpenStack use it, already has plugins for the Gerrit code
> review/git repo management system (at least as customised by the
> OpenStack infrastructure folks), as well as for Jenkins to run the
> automated CI tests.
>
> Rather than suggesting wholesale changes to our own infrastructure,
> what I am suggesting we consider is devoting time (and potentially PSF
> funding) to getting Zuul to play nice with Roundup, Reitveld, BuildBot
> and Mercurial. (Like the rest of our existing infrastructure, Zuul is
> a web service implemented in Python).
>
> The main technical challenges I foresee are:
>
> * dealing with maintenance branches (especially for patches which
> don't merge forward cleanly), since OpenStack currently appear to
> "handle" that limitation by just not providing upstream maintenance
> branches at all, leaving downstream vendors to fill the gap
> * finally cleaning up the way we manage the NEWS file (see
> http://bugs.python.org/issue18967 for discussion)
> * replicating Gerrit's patch approval/voting mechanism in Reitveld
> * replicating Gerrit's merge/rebase capabilities in Mercurial (I'm
> sure Mercurial is functionally capable of this, I just don't know the
> best way to model it).
> * actually writing the new Zuul plugins to talk to the services used
> by the CPython project, rather than those used by OpenStack
>
> There would also be a non-trivial update to the developer guide
> involved in such a change, since it would heavily impact the core
> developer workflows, as well as the way external contributors interact
> with the core development team.
>
> If people find this idea interesting, I would like to invite some of
> the Mercurial devs and OpenStack infrastructure folks (i.e. Zuul devs)
> to the language summit (leaving it up to them if they stay for the
> whole day, or just this part). I believe we already have enough
> Reitveld, Roundup and Buildbot experience amongst the core development
> team to assess the feasibility of the idea from that side of things.
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140118/e3353996/attachment.html>

From ncoghlan at gmail.com  Sun Jan 19 07:30:49 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 19 Jan 2014 16:30:49 +1000
Subject: [python-committers] Commit access for Yury Selivanov?
Message-ID: <CADiSq7cL1vMj3JmeqPXR9TQYsCSdf+B4Uat+r85+5sPW+zVzew@mail.gmail.com>

Hi,

I'd like to suggest granting commit access to Yury Selivanov,
primarily to assist with maintenance of the inspect module.

That's currently an orphaned module in the experts index, and Yury was
a driving force behind getting PEP 362 (the new introspection API)
accepted for Python 3.3, and has also picked up on a number of
introspection support issues we missed when adding other features to
Python 3.4 (like inspect.signature not handling
functools.partialmethod correctly - it simply didn't occur to me or
Alon to add test cases for that). He's also created a reimplementation
of inspect.getfullargspec for Python 3.4 (not yet merged, but close to
being so) that will allow almost all existing introspection code to
benefit from the Argument Clinic changes, not just the code that has
been ported to the new PEP 362 introspection API.

Yury's interested in the idea of commit access, and is comfortable
with our approach to code review and automated testing. As usual when
nominating someone, I'm happy to handle the mentoring period and
addressing any questions Yury may have about the mechanics of actually
pushing changes rather than having to wait for me or Larry or someone
else to merge them on his behalf.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From solipsis at pitrou.net  Sun Jan 19 11:59:25 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 19 Jan 2014 11:59:25 +0100
Subject: [python-committers] LCA2014 presentation on Zuul,
 OpenStack's merge gating system
In-Reply-To: <CADiSq7ejLD=SxoTp_h=mGJO+t5fvOW1QDoq69Z77=PsbmZE_Bw@mail.gmail.com>
References: <CADiSq7ejLD=SxoTp_h=mGJO+t5fvOW1QDoq69Z77=PsbmZE_Bw@mail.gmail.com>
Message-ID: <1390129165.2310.1.camel@fsol>

On dim., 2014-01-19 at 15:34 +1000, Nick Coghlan wrote:
> Rather than suggesting wholesale changes to our own infrastructure,
> what I am suggesting we consider is devoting time (and potentially PSF
> funding) to getting Zuul to play nice with Roundup, Reitveld, BuildBot
> and Mercurial. (Like the rest of our existing infrastructure, Zuul is
> a web service implemented in Python).

Just a minor point: it's Rietveld, not "Reitveld".

Regards

Antoine.



From ncoghlan at gmail.com  Sun Jan 19 13:18:23 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 19 Jan 2014 22:18:23 +1000
Subject: [python-committers] LCA2014 presentation on Zuul,
 OpenStack's merge gating system
In-Reply-To: <1390129165.2310.1.camel@fsol>
References: <CADiSq7ejLD=SxoTp_h=mGJO+t5fvOW1QDoq69Z77=PsbmZE_Bw@mail.gmail.com>
 <1390129165.2310.1.camel@fsol>
Message-ID: <CADiSq7ddSXWzBD=AkCoP3OR28HDzr8Gf_L3FAvaa=OhXM=OoZg@mail.gmail.com>

On 19 January 2014 20:59, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On dim., 2014-01-19 at 15:34 +1000, Nick Coghlan wrote:
>> Rather than suggesting wholesale changes to our own infrastructure,
>> what I am suggesting we consider is devoting time (and potentially PSF
>> funding) to getting Zuul to play nice with Roundup, Reitveld, BuildBot
>> and Mercurial. (Like the rest of our existing infrastructure, Zuul is
>> a web service implemented in Python).
>
> Just a minor point: it's Rietveld, not "Reitveld".

Huh, I think I've been transposing that for years. My confidence in my
ability to retrain my fingers is not high, but I'll try to remember
the right spelling :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From tjreedy at udel.edu  Sun Jan 19 21:34:43 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 19 Jan 2014 15:34:43 -0500
Subject: [python-committers] Commit access for Yury Selivanov?
In-Reply-To: <CADiSq7cL1vMj3JmeqPXR9TQYsCSdf+B4Uat+r85+5sPW+zVzew@mail.gmail.com>
References: <CADiSq7cL1vMj3JmeqPXR9TQYsCSdf+B4Uat+r85+5sPW+zVzew@mail.gmail.com>
Message-ID: <52DC36E3.6070709@udel.edu>

On 1/19/2014 1:30 AM, Nick Coghlan wrote:
> Hi,
>
> I'd like to suggest granting commit access to Yury Selivanov,
> primarily to assist with maintenance of the inspect module.
>
> That's currently an orphaned module in the experts index, and Yury was
> a driving force behind getting PEP 362 (the new introspection API)
> accepted for Python 3.3, and has also picked up on a number of
> introspection support issues we missed when adding other features to
> Python 3.4 (like inspect.signature not handling
> functools.partialmethod correctly - it simply didn't occur to me or
> Alon to add test cases for that). He's also created a reimplementation
> of inspect.getfullargspec for Python 3.4 (not yet merged, but close to
> being so) that will allow almost all existing introspection code to
> benefit from the Argument Clinic changes, not just the code that has
> been ported to the new PEP 362 introspection API.
>
> Yury's interested in the idea of commit access, and is comfortable
> with our approach to code review and automated testing. As usual when
> nominating someone, I'm happy to handle the mentoring period and
> addressing any questions Yury may have about the mechanics of actually
> pushing changes rather than having to wait for me or Larry or someone
> else to merge them on his behalf.

For anyone looking, he has posted on the tracker as both 'yselivanov' (2 
years) and 'Yury.Selivanov' (3 1/2 years). He has submitted patches on 
about 12 issues, 7 closesd, and commented on another 10. These are 
mostly issue I have not be active on, but the numbers are typical for 
when we think about promoting someone.

Terry



From solipsis at pitrou.net  Sun Jan 19 21:41:24 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 19 Jan 2014 21:41:24 +0100
Subject: [python-committers] Commit access for Yury Selivanov?
In-Reply-To: <52DC36E3.6070709@udel.edu>
References: <CADiSq7cL1vMj3JmeqPXR9TQYsCSdf+B4Uat+r85+5sPW+zVzew@mail.gmail.com>
 <52DC36E3.6070709@udel.edu>
Message-ID: <1390164084.3067.2.camel@fsol>

On dim., 2014-01-19 at 15:34 -0500, Terry Reedy wrote:
> For anyone looking, he has posted on the tracker as both 'yselivanov' (2 
> years) and 'Yury.Selivanov' (3 1/2 years). He has submitted patches on 
> about 12 issues, 7 closesd, and commented on another 10. These are 
> mostly issue I have not be active on, but the numbers are typical for 
> when we think about promoting someone.

That's rather on the low side. Browsing through the Mercurial logs, not
many commits actually bear Yury's name.

Since Nick is vouching for him, I'm not against access being granted,
but he'll probably need a fair amount of mentoring before being
trustable for autonomous work, IMHO.

Regards

Antoine.



From victor.stinner at gmail.com  Sun Jan 19 23:06:02 2014
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sun, 19 Jan 2014 23:06:02 +0100
Subject: [python-committers] Commit access for Yury Selivanov?
In-Reply-To: <52DC36E3.6070709@udel.edu>
References: <CADiSq7cL1vMj3JmeqPXR9TQYsCSdf+B4Uat+r85+5sPW+zVzew@mail.gmail.com>
 <52DC36E3.6070709@udel.edu>
Message-ID: <CAMpsgwZE1P8+eRPQ2F1miFo2rYpcVxhoqLp0EVs3CoJKxwSoog@mail.gmail.com>

Is it enough to know the python process and how to write good patches? I
don't see why Yury would become but not Vajrasky Kok.

I never liked how much time it takes to become a "core developer".
Developers know what it means to be core developer and usually ensure that
they don't make mistake.

I didn't see Yury's work, so I'm unable to pronouce me about him. I'm just
trying to figure out how his profile is different from Vajrasky's profile.
By the way, I also proposed to mentor Vajrasky.

Victor
Le 19 janv. 2014 21:34, "Terry Reedy" <tjreedy at udel.edu> a ?crit :

> On 1/19/2014 1:30 AM, Nick Coghlan wrote:
>
>> Hi,
>>
>> I'd like to suggest granting commit access to Yury Selivanov,
>> primarily to assist with maintenance of the inspect module.
>>
>> That's currently an orphaned module in the experts index, and Yury was
>> a driving force behind getting PEP 362 (the new introspection API)
>> accepted for Python 3.3, and has also picked up on a number of
>> introspection support issues we missed when adding other features to
>> Python 3.4 (like inspect.signature not handling
>> functools.partialmethod correctly - it simply didn't occur to me or
>> Alon to add test cases for that). He's also created a reimplementation
>> of inspect.getfullargspec for Python 3.4 (not yet merged, but close to
>> being so) that will allow almost all existing introspection code to
>> benefit from the Argument Clinic changes, not just the code that has
>> been ported to the new PEP 362 introspection API.
>>
>> Yury's interested in the idea of commit access, and is comfortable
>> with our approach to code review and automated testing. As usual when
>> nominating someone, I'm happy to handle the mentoring period and
>> addressing any questions Yury may have about the mechanics of actually
>> pushing changes rather than having to wait for me or Larry or someone
>> else to merge them on his behalf.
>>
>
> For anyone looking, he has posted on the tracker as both 'yselivanov' (2
> years) and 'Yury.Selivanov' (3 1/2 years). He has submitted patches on
> about 12 issues, 7 closesd, and commented on another 10. These are mostly
> issue I have not be active on, but the numbers are typical for when we
> think about promoting someone.
>
> Terry
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140119/6ed1b8ba/attachment.html>

From ethan at stoneleaf.us  Mon Jan 20 00:23:23 2014
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sun, 19 Jan 2014 15:23:23 -0800
Subject: [python-committers] Commit access for Yury Selivanov?
In-Reply-To: <CAMpsgwZE1P8+eRPQ2F1miFo2rYpcVxhoqLp0EVs3CoJKxwSoog@mail.gmail.com>
References: <CADiSq7cL1vMj3JmeqPXR9TQYsCSdf+B4Uat+r85+5sPW+zVzew@mail.gmail.com>
 <52DC36E3.6070709@udel.edu>
 <CAMpsgwZE1P8+eRPQ2F1miFo2rYpcVxhoqLp0EVs3CoJKxwSoog@mail.gmail.com>
Message-ID: <52DC5E6B.1010508@stoneleaf.us>

On 01/19/2014 02:06 PM, Victor Stinner wrote:
>
> Is it enough to know the python process and how to write good patches?

I would say that's half the battle, but not all of it [1].

> I don't see why Yury would become but not Vajrasky Kok.

I haven't worked with Yury, but I have worked with Vajrasky on three issues for Enum.  He was a huge help in finding 
bugs, and in getting a patch going, but two of those three patches I had to seriously rework (the third, that I could 
use as-is, was very minor).


> I never liked how much time it takes to become a "core developer". Developers know what it means to be core developer
> and usually ensure that they don't make mistake.

I have to disagree.  Developers have the same range in talents and concerns as other folks; not every developer is a 
"core developer".  Likewise, it is possible to be extremely helpful without being a core developer.  While I wasn't able 
to just use Vajrasky's patches as-is, I am still grateful that he found the bugs and inconsistencies so they could be fixed.

--
~Ethan~

[1] "Knowledge is half the battle."

     What's the other half?

       25% red lasers
       25% blue lasers

     More seriously, I would say a core-dev should also be teachable, able to communicate effectively, and good at 
debugging, to name just a few things.

From ncoghlan at gmail.com  Mon Jan 20 05:39:24 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 20 Jan 2014 14:39:24 +1000
Subject: [python-committers] Commit access for Yury Selivanov?
In-Reply-To: <CAMpsgwZE1P8+eRPQ2F1miFo2rYpcVxhoqLp0EVs3CoJKxwSoog@mail.gmail.com>
References: <CADiSq7cL1vMj3JmeqPXR9TQYsCSdf+B4Uat+r85+5sPW+zVzew@mail.gmail.com>
 <52DC36E3.6070709@udel.edu>
 <CAMpsgwZE1P8+eRPQ2F1miFo2rYpcVxhoqLp0EVs3CoJKxwSoog@mail.gmail.com>
Message-ID: <CADiSq7fR8+d8VQTFOQae__cxMvbJncxFLboxaS=8g1tCZ04xdg@mail.gmail.com>

On 20 Jan 2014 08:06, "Victor Stinner" <victor.stinner at gmail.com> wrote:
>
> Is it enough to know the python process and how to write good patches? I
don't see why Yury would become but not Vajrasky Kok.

In this case, it's Yury's specific contributions to an orphan module and
being a co-author of an accepted PEP related to that module that motivate
my suggestion, rather than general bug fixing (which I agree would
typically involve a wider range of contributions).

I see it as similar to the way we grant commit access to authors of "add a
module to the standard library" PEPs as a matter of course so they can
continue maintaining it.

Cheers,
Nick.

>
> I never liked how much time it takes to become a "core developer".
Developers know what it means to be core developer and usually ensure that
they don't make mistake.
>
> I didn't see Yury's work, so I'm unable to pronouce me about him. I'm
just trying to figure out how his profile is different from Vajrasky's
profile. By the way, I also proposed to mentor Vajrasky.
>
> Victor
>
> Le 19 janv. 2014 21:34, "Terry Reedy" <tjreedy at udel.edu> a ?crit :
>
>> On 1/19/2014 1:30 AM, Nick Coghlan wrote:
>>>
>>> Hi,
>>>
>>> I'd like to suggest granting commit access to Yury Selivanov,
>>> primarily to assist with maintenance of the inspect module.
>>>
>>> That's currently an orphaned module in the experts index, and Yury was
>>> a driving force behind getting PEP 362 (the new introspection API)
>>> accepted for Python 3.3, and has also picked up on a number of
>>> introspection support issues we missed when adding other features to
>>> Python 3.4 (like inspect.signature not handling
>>> functools.partialmethod correctly - it simply didn't occur to me or
>>> Alon to add test cases for that). He's also created a reimplementation
>>> of inspect.getfullargspec for Python 3.4 (not yet merged, but close to
>>> being so) that will allow almost all existing introspection code to
>>> benefit from the Argument Clinic changes, not just the code that has
>>> been ported to the new PEP 362 introspection API.
>>>
>>> Yury's interested in the idea of commit access, and is comfortable
>>> with our approach to code review and automated testing. As usual when
>>> nominating someone, I'm happy to handle the mentoring period and
>>> addressing any questions Yury may have about the mechanics of actually
>>> pushing changes rather than having to wait for me or Larry or someone
>>> else to merge them on his behalf.
>>
>>
>> For anyone looking, he has posted on the tracker as both 'yselivanov' (2
years) and 'Yury.Selivanov' (3 1/2 years). He has submitted patches on
about 12 issues, 7 closesd, and commented on another 10. These are mostly
issue I have not be active on, but the numbers are typical for when we
think about promoting someone.
>>
>> Terry
>>
>>
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140120/3e7bc365/attachment.html>

From ethan at stoneleaf.us  Mon Jan 20 20:44:31 2014
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 20 Jan 2014 11:44:31 -0800
Subject: [python-committers] Commit right for Vajrasky Kok?
In-Reply-To: <20140109153418.7F8A725044D@webabinitio.net>
References: <CAMpsgwYVXuXSqhybmU171YcjzWtgmrQvH8G=diN7po=K3u4ZZw@mail.gmail.com>
 <1642791.96NxDDDZkS@raxxla> <20140109153418.7F8A725044D@webabinitio.net>
Message-ID: <52DD7C9F.3090003@stoneleaf.us>

On 01/09/2014 07:34 AM, R. David Murray wrote:
> On Thu, 09 Jan 2014 16:23:59 +0200, Serhiy Storchaka wrote:
>>
>> Vajrasky Kok is good candidate. He is very active and interested in Python
>> maintaining, he is respondable. he makes review of others code. But his code
>> still not mature. He is often doesn't noticed many details in first versions of
>> his patches. He just lacks experience. I believe that a year late he will be
>> more experienced.
>>
>> Sorry, I'm -0.1 for right now.
>
> I agree with this assessment.  It might not take a year, but I don't
> think the time is quite yet.  Please feel free to encourage him, though.
>
> To put Serhiy's summary another way, we haven't quite reached the point
> where it would be easier for us if he could just commit his own patches.

I agree with the above.  Promising, but not ready yet.

Also, on another thread I wrote:
>
> More seriously, I would say a core-dev should also be teachable, able
> to communicate effectively, and good at debugging, to name just a few
> things.

This sentence was meant in general, not that Vajrasky doesn't have them.  I would say he is good at communicating and 
debugging, it's just the quality of the patches that keeps me from voting for him at this point.

--
~Ethan~

From ncoghlan at gmail.com  Tue Jan 21 00:03:19 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 21 Jan 2014 09:03:19 +1000
Subject: [python-committers] LCA2014 presentation on Zuul,
 OpenStack's merge gating system
In-Reply-To: <CAK1Qooozd54a2GHG5q3wu+JCC0MZCqQ5xcnKY9ziN2=Qr0Jv=Q@mail.gmail.com>
References: <CADiSq7ejLD=SxoTp_h=mGJO+t5fvOW1QDoq69Z77=PsbmZE_Bw@mail.gmail.com>
 <CAK1Qooozd54a2GHG5q3wu+JCC0MZCqQ5xcnKY9ziN2=Qr0Jv=Q@mail.gmail.com>
Message-ID: <CADiSq7fCSCkCVcMSq6S_URDuANaZbcNjWVxMA2SP8Zzk5peWRw@mail.gmail.com>

On 21 Jan 2014 01:19, "Meador Inge" <meadori at gmail.com> wrote:
>
> On Sat, Jan 18, 2014 at 11:34 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> If people find this idea interesting, I would like to invite some of
>> the Mercurial devs and OpenStack infrastructure folks (i.e. Zuul devs)
>> to the language summit (leaving it up to them if they stay for the
>> whole day, or just this part). I believe we already have enough
>> Reitveld, Roundup and Buildbot experience amongst the core development
>> team to assess the feasibility of the idea from that side of things.
>
>
> I find the idea interesting and plan to watch the linked video and
> read up on this.  Is it an all or nothing thing (i.e. either all devs
> operate using the new Zull-based method or no one does)?

All-or-nothing - with merge gating, *only* Zuul commits to the main
branches/clone (so we'd also be in for some interesting discussions with
the release managers and installer buiders - we may need to provide them
with the ability to override the normal gating process).

The underlying philosophy of the approach is reflected in the fact that
OpenStack doesn't have core committers or even core developers - they have
core reviewers instead.

Cheers,
Nick.

>
> --
> # Meador
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140121/2ef1be38/attachment.html>

From tjreedy at udel.edu  Mon Jan 20 23:54:03 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 20 Jan 2014 17:54:03 -0500
Subject: [python-committers] Commit right for Vajrasky Kok?
In-Reply-To: <52DD7C9F.3090003@stoneleaf.us>
References: <CAMpsgwYVXuXSqhybmU171YcjzWtgmrQvH8G=diN7po=K3u4ZZw@mail.gmail.com>
 <1642791.96NxDDDZkS@raxxla> <20140109153418.7F8A725044D@webabinitio.net>
 <52DD7C9F.3090003@stoneleaf.us>
Message-ID: <52DDA90B.5080207@udel.edu>

I agree with 'promising'. I cannot comment on 'ready' as I have not 
reviewed his patches much. My impression is that he has a talent for 
noticing glitches in the details of existing behavior and docs.

"He is often doesn't noticed many details in first versions of his patches."

If he has trouble being as critical of his own work, he would not be the 
first. It is a needed skill, though.

Has anyone communicated with him, perhaps privately, on how to improve 
his patches, so he learns by doing it himself? (I know very well that 
editing and commiting is often more expeditious if one wants the patch 
committed *now*.) Mentoring, if he wants it, could start now rather than 
after granting commit rights.

Terry


From ethan at stoneleaf.us  Tue Jan 21 01:19:21 2014
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 20 Jan 2014 16:19:21 -0800
Subject: [python-committers] Commit right for Vajrasky Kok?
In-Reply-To: <52DDA90B.5080207@udel.edu>
References: <CAMpsgwYVXuXSqhybmU171YcjzWtgmrQvH8G=diN7po=K3u4ZZw@mail.gmail.com>
 <1642791.96NxDDDZkS@raxxla> <20140109153418.7F8A725044D@webabinitio.net>
 <52DD7C9F.3090003@stoneleaf.us> <52DDA90B.5080207@udel.edu>
Message-ID: <52DDBD09.7090308@stoneleaf.us>

On 01/20/2014 02:54 PM, Terry Reedy wrote:
>
> I agree with 'promising'. I cannot comment on 'ready' as I have not reviewed his patches much. My impression is that he
> has a talent for noticing glitches in the details of existing behavior and docs.

Which is an important skill of its own.


> Has anyone communicated with him, perhaps privately, on how to improve his patches, so he learns by doing it himself?

I have not, but am willing to if Victor would not be offended.  I don't feel up to being an official mentor as the 
machinery and protocols are still new to me, but I think I could offer sound advice on how to improve his patch and 
debugging skills.

--
~Ethan~

From victor.stinner at gmail.com  Tue Jan 21 02:45:07 2014
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 21 Jan 2014 02:45:07 +0100
Subject: [python-committers] Commit right for Vajrasky Kok?
In-Reply-To: <52DDBD09.7090308@stoneleaf.us>
References: <CAMpsgwYVXuXSqhybmU171YcjzWtgmrQvH8G=diN7po=K3u4ZZw@mail.gmail.com>
 <1642791.96NxDDDZkS@raxxla> <20140109153418.7F8A725044D@webabinitio.net>
 <52DD7C9F.3090003@stoneleaf.us> <52DDA90B.5080207@udel.edu>
 <52DDBD09.7090308@stoneleaf.us>
Message-ID: <CAMpsgwYeW2AmKKcnQggs6Rj+XDZYX2euRpfgHDB2TBFUy0Basw@mail.gmail.com>

Hi,

2014/1/21 Ethan Furman <ethan at stoneleaf.us>:
>> Has anyone communicated with him, perhaps privately, on how to improve his
>> patches, so he learns by doing it himself?

I contacted him before proposing to give him the commit access.

I then told him that he should just continue his contributions to
reach the requested quality level of the Python project. He replied
that it's hard to find easy issues and that Serhiy fixes most of them.
Vajrasky prefers to hurry to propose a buggy patch, just to be the
first one, instead of seen the issue stolen from Serhiy.

I experimented the difficult task of finding "easy" issues. I agree
that it's a very hard task. Recent easy issues are closed in less than
one week, sometimes in 24 hours. Old issues are usually hard, specific
to an user or platform, tricky to implement, etc.

There is maybe something wrong in our process about easy issues?

Obviously, I asked asked Vajrasky to contact Serhiy to stop this race.

> I have not, but am willing to if Victor would not be offended.  I don't feel
> up to being an official mentor as the machinery and protocols are still new
> to me, but I think I could offer sound advice on how to improve his patch
> and debugging skills.

Oh please, do :-) I'm not offended. Or exchanges may be "public" in
the mentor mailing list? As Vajrasky prefers.

Victor

From ncoghlan at gmail.com  Thu Jan 23 04:01:58 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 23 Jan 2014 13:01:58 +1000
Subject: [python-committers] Commit access for Yury Selivanov?
In-Reply-To: <CADiSq7fR8+d8VQTFOQae__cxMvbJncxFLboxaS=8g1tCZ04xdg@mail.gmail.com>
References: <CADiSq7cL1vMj3JmeqPXR9TQYsCSdf+B4Uat+r85+5sPW+zVzew@mail.gmail.com>
 <52DC36E3.6070709@udel.edu>
 <CAMpsgwZE1P8+eRPQ2F1miFo2rYpcVxhoqLp0EVs3CoJKxwSoog@mail.gmail.com>
 <CADiSq7fR8+d8VQTFOQae__cxMvbJncxFLboxaS=8g1tCZ04xdg@mail.gmail.com>
Message-ID: <CADiSq7ce05Lkr-ubp5DGd75PcOx0QozYt8qQd=+ULDa+rcit2Q@mail.gmail.com>

On 20 January 2014 14:39, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 20 Jan 2014 08:06, "Victor Stinner" <victor.stinner at gmail.com> wrote:
>>
>> Is it enough to know the python process and how to write good patches? I
>> don't see why Yury would become but not Vajrasky Kok.
>
> In this case, it's Yury's specific contributions to an orphan module and
> being a co-author of an accepted PEP related to that module that motivate my
> suggestion, rather than general bug fixing (which I agree would typically
> involve a wider range of contributions).
>
> I see it as similar to the way we grant commit access to authors of "add a
> module to the standard library" PEPs as a matter of course so they can
> continue maintaining it.

Ping?

Yury's someone I run *my* inspect module changes by, so it would
definitely make my life easier if I could +1 his patches and he could
take care of committing and pushing them himself.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From benjamin at python.org  Thu Jan 23 04:05:47 2014
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 22 Jan 2014 19:05:47 -0800
Subject: [python-committers] Commit access for Yury Selivanov?
In-Reply-To: <CADiSq7ce05Lkr-ubp5DGd75PcOx0QozYt8qQd=+ULDa+rcit2Q@mail.gmail.com>
References: <CADiSq7cL1vMj3JmeqPXR9TQYsCSdf+B4Uat+r85+5sPW+zVzew@mail.gmail.com>
 <52DC36E3.6070709@udel.edu>
 <CAMpsgwZE1P8+eRPQ2F1miFo2rYpcVxhoqLp0EVs3CoJKxwSoog@mail.gmail.com>
 <CADiSq7fR8+d8VQTFOQae__cxMvbJncxFLboxaS=8g1tCZ04xdg@mail.gmail.com>
 <CADiSq7ce05Lkr-ubp5DGd75PcOx0QozYt8qQd=+ULDa+rcit2Q@mail.gmail.com>
Message-ID: <1390446347.11759.74224085.13DB6E6B@webmail.messagingengine.com>

On Wed, Jan 22, 2014, at 07:01 PM, Nick Coghlan wrote:
> On 20 January 2014 14:39, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >
> > On 20 Jan 2014 08:06, "Victor Stinner" <victor.stinner at gmail.com> wrote:
> >>
> >> Is it enough to know the python process and how to write good patches? I
> >> don't see why Yury would become but not Vajrasky Kok.
> >
> > In this case, it's Yury's specific contributions to an orphan module and
> > being a co-author of an accepted PEP related to that module that motivate my
> > suggestion, rather than general bug fixing (which I agree would typically
> > involve a wider range of contributions).
> >
> > I see it as similar to the way we grant commit access to authors of "add a
> > module to the standard library" PEPs as a matter of course so they can
> > continue maintaining it.
> 
> Ping?
> 
> Yury's someone I run *my* inspect module changes by, so it would
> definitely make my life easier if I could +1 his patches and he could
> take care of committing and pushing them himself.

I don't see anyone complaining too loudly, so have him send his key to
hgaccounts at python.org.

From eric at trueblade.com  Thu Jan 23 08:34:04 2014
From: eric at trueblade.com (Eric V. Smith)
Date: Thu, 23 Jan 2014 02:34:04 -0500
Subject: [python-committers] Commit access for Yury Selivanov?
In-Reply-To: <1390446347.11759.74224085.13DB6E6B@webmail.messagingengine.com>
References: <CADiSq7cL1vMj3JmeqPXR9TQYsCSdf+B4Uat+r85+5sPW+zVzew@mail.gmail.com>
 <52DC36E3.6070709@udel.edu>
 <CAMpsgwZE1P8+eRPQ2F1miFo2rYpcVxhoqLp0EVs3CoJKxwSoog@mail.gmail.com>
 <CADiSq7fR8+d8VQTFOQae__cxMvbJncxFLboxaS=8g1tCZ04xdg@mail.gmail.com>
 <CADiSq7ce05Lkr-ubp5DGd75PcOx0QozYt8qQd=+ULDa+rcit2Q@mail.gmail.com>
 <1390446347.11759.74224085.13DB6E6B@webmail.messagingengine.com>
Message-ID: <52E0C5EC.1060103@trueblade.com>

On 1/22/2014 10:05 PM, Benjamin Peterson wrote:
> I don't see anyone complaining too loudly, so have him send his key to
> hgaccounts at python.org.

I've added him to python-committers. Welcome, Yury!

Eric.



From ethan at stoneleaf.us  Thu Jan 23 14:50:30 2014
From: ethan at stoneleaf.us (Ethan Furman)
Date: Thu, 23 Jan 2014 05:50:30 -0800
Subject: [python-committers] Commit access for Yury Selivanov?
In-Reply-To: <52E0C5EC.1060103@trueblade.com>
References: <CADiSq7cL1vMj3JmeqPXR9TQYsCSdf+B4Uat+r85+5sPW+zVzew@mail.gmail.com>
 <52DC36E3.6070709@udel.edu>
 <CAMpsgwZE1P8+eRPQ2F1miFo2rYpcVxhoqLp0EVs3CoJKxwSoog@mail.gmail.com>
 <CADiSq7fR8+d8VQTFOQae__cxMvbJncxFLboxaS=8g1tCZ04xdg@mail.gmail.com>
 <CADiSq7ce05Lkr-ubp5DGd75PcOx0QozYt8qQd=+ULDa+rcit2Q@mail.gmail.com>
 <1390446347.11759.74224085.13DB6E6B@webmail.messagingengine.com>
 <52E0C5EC.1060103@trueblade.com>
Message-ID: <52E11E26.7030809@stoneleaf.us>

On 01/22/2014 11:34 PM, Eric V. Smith wrote:
>
> Welcome, Yury!

Congratulations, Yury!

--
~Ethan~

From yselivanov.ml at gmail.com  Thu Jan 23 17:32:35 2014
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Thu, 23 Jan 2014 11:32:35 -0500
Subject: [python-committers] introduction
Message-ID: <52E14423.7090901@gmail.com>

Hello,

Thank you very much for accepting me as a member of your team!
Python is the most beautiful, simple and complex language I
ever knew, and it's an honor for me to help to make it better.

Just to give you an idea of how passionate I am about python,
I'd like to tell you a short story.  When I just started to
work on PEP 362 with Brett and Larry, we had a few discussions
of how things should be going and I promised them to draft a
first version of the PEP and implementation by the end of the
week. On Friday, I decided to make a surprise for my girlfriend
and booked a weekend in Montreal, and in the morning of
Saturday I woke up with a fever of 37 degrees. Well, it's just
37, I'll be OK by the time we drive there. Hell I was wrong.
For two days, the only thing I was romantically attached to,
was my bed in the hotel room. And midday of Sunday, I realized
that I have a promise to fulfill. So here I was, sitting on the
bed, with a fever of 39 degrees, with one eye closed, and the
other one so filled with tears so I had to squish it to have
a clear spot on the screen, working on that draft and writing
unittests. All because I knew that while it'd be OK to wait a
few days, we didn't actually have time for that, because the
release was just around the corner, and every day was important.

So, again, thank you very much!  I now have to break the
buildbot I guess..

Yury

From zachary.ware+pycommit at gmail.com  Thu Jan 23 17:42:55 2014
From: zachary.ware+pycommit at gmail.com (Zachary Ware)
Date: Thu, 23 Jan 2014 10:42:55 -0600
Subject: [python-committers] introduction
In-Reply-To: <52E14423.7090901@gmail.com>
References: <52E14423.7090901@gmail.com>
Message-ID: <CAKJDb-NHBNZTARW4c66hL0iVNPGYL8ztz=nk41hqfM4cPY7jYQ@mail.gmail.com>

Welcome, Yury!

From solipsis at pitrou.net  Thu Jan 23 19:38:11 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 23 Jan 2014 19:38:11 +0100
Subject: [python-committers] introduction
In-Reply-To: <52E14423.7090901@gmail.com>
References: <52E14423.7090901@gmail.com>
Message-ID: <1390502291.2293.9.camel@fsol>


Hello Yury,

> So here I was, sitting on the
> bed, with a fever of 39 degrees, with one eye closed, and the
> other one so filled with tears so I had to squish it to have
> a clear spot on the screen, working on that draft and writing
> unittests. All because I knew that while it'd be OK to wait a
> few days, we didn't actually have time for that, because the
> release was just around the corner, and every day was important.

Word has it that all great Python decisions were made either in a
feverish or inebriated state :) Welcome aboard!

Regards

Antoine.



From andrew.svetlov at gmail.com  Thu Jan 23 19:56:48 2014
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Thu, 23 Jan 2014 20:56:48 +0200
Subject: [python-committers] introduction
In-Reply-To: <CAKJDb-NHBNZTARW4c66hL0iVNPGYL8ztz=nk41hqfM4cPY7jYQ@mail.gmail.com>
References: <52E14423.7090901@gmail.com>
 <CAKJDb-NHBNZTARW4c66hL0iVNPGYL8ztz=nk41hqfM4cPY7jYQ@mail.gmail.com>
Message-ID: <CAL3CFcUcweEckof3QCtqGNaHU=1qJ4J+TONYfitEQAhD+H=Lvg@mail.gmail.com>

Welcome!

On Thu, Jan 23, 2014 at 6:42 PM, Zachary Ware
<zachary.ware+pycommit at gmail.com> wrote:
> Welcome, Yury!
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers



-- 
Thanks,
Andrew Svetlov

From eliben at gmail.com  Thu Jan 23 20:29:29 2014
From: eliben at gmail.com (Eli Bendersky)
Date: Thu, 23 Jan 2014 11:29:29 -0800
Subject: [python-committers] introduction
In-Reply-To: <1390502291.2293.9.camel@fsol>
References: <52E14423.7090901@gmail.com> <1390502291.2293.9.camel@fsol>
Message-ID: <CAF-Rda9FUvYLo3LJWDHnkraBaMgcD01j1d-iFBuSDM2mVk-qtg@mail.gmail.com>

On Thu, Jan 23, 2014 at 10:38 AM, Antoine Pitrou <solipsis at pitrou.net>wrote:

>
> Hello Yury,
>
> > So here I was, sitting on the
> > bed, with a fever of 39 degrees, with one eye closed, and the
> > other one so filled with tears so I had to squish it to have
> > a clear spot on the screen, working on that draft and writing
> > unittests. All because I knew that while it'd be OK to wait a
> > few days, we didn't actually have time for that, because the
> > release was just around the corner, and every day was important.
>
> Word has it that all great Python decisions were made either in a
> feverish or inebriated state :) Welcome aboard!
>

Ah... now I understand how the for..else syntax made it into the language.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140123/1583ba65/attachment.html>

From ncoghlan at gmail.com  Fri Jan 24 01:15:04 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 24 Jan 2014 10:15:04 +1000
Subject: [python-committers] introduction
In-Reply-To: <52E14423.7090901@gmail.com>
References: <52E14423.7090901@gmail.com>
Message-ID: <CADiSq7f1D_zTWJWGg3NSe-BcmbwGwgozUKvJ3fT5t8A3=W8Gfg@mail.gmail.com>

On 24 Jan 2014 02:32, "Yury Selivanov" <yselivanov.ml at gmail.com> wrote:
>
> Hello,
>
> Thank you very much for accepting me as a member of your team!
> Python is the most beautiful, simple and complex language I
> ever knew, and it's an honor for me to help to make it better.

Welcome! :)

> So, again, thank you very much!  I now have to break the
> buildbot I guess..

Performance tests or something filesystem related would be traditional on
that front ;)

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140124/b0f7bc66/attachment-0001.html>

From ncoghlan at gmail.com  Sat Jan 25 06:51:38 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 25 Jan 2014 15:51:38 +1000
Subject: [python-committers] PEP 462: Workflow automation for CPython
Message-ID: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>

Hey all,

Rather than leaving my ideas undocumented until the language summit in
April, I wrote up what I see as the critical issues in our current
workflow and how I believe Zuul could help us resolve them as a PEP:
http://www.python.org/dev/peps/pep-0462/

I don't think we should *do* anything about this until after PyCon US,
but wanted to publish something that clearly explained my thinking
rather than surprising people with it at the summit.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From larry at hastings.org  Sat Jan 25 14:09:27 2014
From: larry at hastings.org (Larry Hastings)
Date: Sat, 25 Jan 2014 05:09:27 -0800
Subject: [python-committers] Status of the Derby,
	and request for another slip
Message-ID: <52E3B787.7070101@hastings.org>



The Great Argument Clinic Conversion Derby has been underway for about 
2.5 weeks.  Here's a status update.  I'll try to keep this short.

It's taking a lot longer than I expected it to.  This has been due to
* bugs and flaws in Argument Clinic itself (a "flaw" is an "I didn't 
foresee that" design error),
* having to make changes to CPython itself, which required *very* 
careful work and was therefore quite time consuming, and
* my time being a huge bottleneck.

I'd like to extend the Derby by two more weeks and add a fourth beta.

--

I've made huge improvements to the implementation of Argument Clinic, in 
response to bugs filed and crippling-missing-features requested.  
Argument Clinic is growing more sophisticated by the day.

I've also, regrettably, made some modifications to CPython, to better 
support signatures in builtins.  In particular, I had to modify four 
additional callable types to add support for "__text_signature__", 
including PyTypeObject.  These changes were reviewed by Nick and Guido, 
so I have a high confidence that the changes will not destabilize Python 
3.4.  (If there is demand, I can compile a list of all such 
arguably-not-a-bugfix post-feature-freeze changes to Python 3.4 if 
there's interest.)


The main problem with running the Derby: everything is gated on me. 
Until just recently, I've had to review every patch, and I've had to 
make every modification to clinic.py.  I've been spending all day, every 
day, with very little time off, on the Derby, and still it's nowhere 
near enough.

This is changing, slowly.  I now have a handful of people who make small 
changes to clinic.py or review patches.  But major brain surgery on the 
tool is still up to me, and I still have a half-week's worth of work on 
my to-do list.

I've been prioritizing bug fixes and crippling missing features over 
reviewing patches.  (I figured that would maximize the productivity of 
the Derby participants.)  As a result, I have a patch backlog that would 
makes you cry.  I've been reviewing patches FIFO, and the patch waiting 
at the front of my queue is ten days old.

This means that a lot of the conversion work done for the Derby has not 
been checked in yet.

To be honest I have absolutely no idea what % of files have been 
converted so far.  Figuring it out would use time that would be better 
spent catching up on my to-do list.

--

I'd like to continue the Derby for two more weeks and insert a fourth 
beta.  That would put the release date for Python 3.4 final on March 31st.

With the new conversion policy in place (see my recent posting to 
python-dev), the number of new surprises that I would have to spend time 
on should drop to about zero.  (My new answer: "That will have to wait 
until 3.5.")  I have about a half-week's worth of bug fixes / missing 
features work for clinic.py right now; once that's done I'll be able to 
spend nearly all of my time on code reviews.  (If I catch up, I might 
even start doing conversions myself!)  So I expect the pace of the Derby 
to ramp up in the coming week.

I *would* ask for three more weeks, not two, just to be dead certain we 
finish before rc1.  But then the release date for 3.4 final would be 
April 7th, two days before the start of PyCon US 2014, and I don't want 
to shave it that close.  If we had to slip again for some reason, we'd 
be cutting the release *during* PyCon US, and I want to avoid *that* at 
all costs, particularly as that may be impractical for the platform 
release manager (their build environment may not be portable).  I want 
3.4 out before PyCon US so that trunk is open for 3.5 during the dev 
sprints.


The alternative would be: stop all submissions to the Derby right now, 
iterate (quickly!) on the existing patches, check them in, and proceed 
to rc1.


In theory, as release manager I could simply announce we were doing 
this.  However, I only want to continue doing this if I have approval 
from the core dev community.  If slipping the schedule again means a 
majority of people withdraw their support for the Derby, then it would 
probably be best to cut our losses now.


Please vote for either "continue the Derby" (which also means slipping 
the schedule and adding a fourth beta) or "stop the Derby".


Thank you for your attention,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140125/e37ffddc/attachment.html>

From solipsis at pitrou.net  Sat Jan 25 14:35:03 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 25 Jan 2014 14:35:03 +0100
Subject: [python-committers] Status of the Derby,
 and request for another slip
In-Reply-To: <52E3B787.7070101@hastings.org>
References: <52E3B787.7070101@hastings.org>
Message-ID: <1390656903.2300.0.camel@fsol>

On sam., 2014-01-25 at 05:09 -0800, Larry Hastings wrote:
> 
> Please vote for either "continue the Derby" (which also means slipping
> the schedule and adding a fourth beta) or "stop the Derby".

Stop the Derby. We needn't convert everything for 3.4 (I didn't even
know that was your goal).

Regards

Antoine.



From larry at hastings.org  Sat Jan 25 14:49:49 2014
From: larry at hastings.org (Larry Hastings)
Date: Sat, 25 Jan 2014 05:49:49 -0800
Subject: [python-committers] Status of the Derby,
 and request for another slip
In-Reply-To: <1390656903.2300.0.camel@fsol>
References: <52E3B787.7070101@hastings.org> <1390656903.2300.0.camel@fsol>
Message-ID: <52E3C0FD.5060908@hastings.org>

On 01/25/2014 05:35 AM, Antoine Pitrou wrote:
> Stop the Derby. We needn't convert everything for 3.4 (I didn't even
> know that was your goal).

Converting everything was my goal at one point.  At this point it is 
nowhere near viable, not the least because there simply isn't enough 
time.  As discussed yesterday on python-dev (subject: "Argument Clinic: 
what to do with builtins with non-standard signatures?"), and today 
(subject: "New policies for the Derby -- please read!"), there are large 
numbers of functions in Python 3.4 that have signatures that can't be 
expressed by inspect.Signature without semantic changes.  Since we can't 
make those changes for 3.4, we can't convert them to Argument Clinic yet.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140125/b2fcdac9/attachment.html>

From eliben at gmail.com  Sat Jan 25 14:49:56 2014
From: eliben at gmail.com (Eli Bendersky)
Date: Sat, 25 Jan 2014 05:49:56 -0800
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
Message-ID: <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>

Interesting. Chromium has something kind-of similar, named "commit queue",
for developers without actual commit access. Once they get an LGTM, the
thing rolls automatically. In fact, core developers often find it useful
too because the Chromium tree is sometimes closed ("red"). We don't really
do the latter in Python, which carries a problem we'll probably need to
resolve first - how to know that the bots are green enough. That really
needs human attention.

Eli


On Fri, Jan 24, 2014 at 9:51 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Hey all,
>
> Rather than leaving my ideas undocumented until the language summit in
> April, I wrote up what I see as the critical issues in our current
> workflow and how I believe Zuul could help us resolve them as a PEP:
> http://www.python.org/dev/peps/pep-0462/
>
> I don't think we should *do* anything about this until after PyCon US,
> but wanted to publish something that clearly explained my thinking
> rather than surprising people with it at the summit.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140125/d83d1582/attachment-0001.html>

From rdmurray at bitdance.com  Sat Jan 25 15:14:54 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 25 Jan 2014 09:14:54 -0500
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
Message-ID: <20140125141454.C91B5250058@webabinitio.net>

On Sat, 25 Jan 2014 05:49:56 -0800, Eli Bendersky <eliben at gmail.com> wrote:
> do the latter in Python, which carries a problem we'll probably need to
> resolve first - how to know that the bots are green enough. That really
> needs human attention.

By "that needs human attention", do you mean: dealing with the remaining
flaky tests, so that "stable buildbots are green" is a binary decision?
We strive for that now, but Nick's proposal would mean we'd have to
finally buckle down and complete the work.  I'm sure we'd make some new
flaky tests at some point, but in this future they'd become show-stoppers
until they were fixed.  I think this would be a good thing, overall :)

--David

From eliben at gmail.com  Sat Jan 25 15:35:59 2014
From: eliben at gmail.com (Eli Bendersky)
Date: Sat, 25 Jan 2014 06:35:59 -0800
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <20140125141454.C91B5250058@webabinitio.net>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <20140125141454.C91B5250058@webabinitio.net>
Message-ID: <CAF-Rda_b8N0Xa9Wv5SthUU17p3O15EgYrQEHL5LkzCUcLyKzAw@mail.gmail.com>

On Sat, Jan 25, 2014 at 6:14 AM, R. David Murray <rdmurray at bitdance.com>wrote:

> On Sat, 25 Jan 2014 05:49:56 -0800, Eli Bendersky <eliben at gmail.com>
> wrote:
> > do the latter in Python, which carries a problem we'll probably need to
> > resolve first - how to know that the bots are green enough. That really
> > needs human attention.
>
> By "that needs human attention", do you mean: dealing with the remaining
> flaky tests, so that "stable buildbots are green" is a binary decision?
> We strive for that now, but Nick's proposal would mean we'd have to
> finally buckle down and complete the work.  I'm sure we'd make some new
> flaky tests at some point, but in this future they'd become show-stoppers
> until they were fixed.  I think this would be a good thing, overall :)
>

Non-flakiness of bots is a holy grail few projects attain. If your bots are
consistently green with no flakes, it just means you're not testing enough
:-)

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140125/5aeb92b8/attachment.html>

From dirkjan at ochtman.nl  Sat Jan 25 15:54:56 2014
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Sat, 25 Jan 2014 15:54:56 +0100
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
Message-ID: <CAKmKYaDv+WDrr2BGj+n3ERG1ooEaG5Y8uh93YsMTsnx2w4pAXg@mail.gmail.com>

On Sat, Jan 25, 2014 at 2:49 PM, Eli Bendersky <eliben at gmail.com> wrote:
> Interesting. Chromium has something kind-of similar, named "commit queue",
> for developers without actual commit access. Once they get an LGTM, the
> thing rolls automatically. In fact, core developers often find it useful too
> because the Chromium tree is sometimes closed ("red"). We don't really do
> the latter in Python, which carries a problem we'll probably need to resolve
> first - how to know that the bots are green enough. That really needs human
> attention.

Another interesting (and relevant, I think) concept from the Mozilla
community is the Try Server, where you can push a work-in-progress
patch to see how it does on all the platforms. I.e. it runs all the
same tests that build slaves run, but the repository it works against
isn't accessible publicly, so you can try your work without breaking
the main tree.

Cheers,

Dirkjan

From eliben at gmail.com  Sat Jan 25 15:59:19 2014
From: eliben at gmail.com (Eli Bendersky)
Date: Sat, 25 Jan 2014 06:59:19 -0800
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <CAKmKYaDv+WDrr2BGj+n3ERG1ooEaG5Y8uh93YsMTsnx2w4pAXg@mail.gmail.com>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <CAKmKYaDv+WDrr2BGj+n3ERG1ooEaG5Y8uh93YsMTsnx2w4pAXg@mail.gmail.com>
Message-ID: <CAF-Rda-sE6QOjAvFriwVt79W92yfrs3+eomNRT4=n5es7-ZjNw@mail.gmail.com>

On Sat, Jan 25, 2014 at 6:54 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:

> On Sat, Jan 25, 2014 at 2:49 PM, Eli Bendersky <eliben at gmail.com> wrote:
> > Interesting. Chromium has something kind-of similar, named "commit
> queue",
> > for developers without actual commit access. Once they get an LGTM, the
> > thing rolls automatically. In fact, core developers often find it useful
> too
> > because the Chromium tree is sometimes closed ("red"). We don't really do
> > the latter in Python, which carries a problem we'll probably need to
> resolve
> > first - how to know that the bots are green enough. That really needs
> human
> > attention.
>
> Another interesting (and relevant, I think) concept from the Mozilla
> community is the Try Server, where you can push a work-in-progress
> patch to see how it does on all the platforms. I.e. it runs all the
> same tests that build slaves run, but the repository it works against
> isn't accessible publicly, so you can try your work without breaking
> the main tree.
>

Yep, Chromium has try-jobs too, thanks for reminding me. And in a previous
workplace we had a similar process screwed on top of Jenkins - private test
runs wherein you provide a branch to CI and the CI tests that branch. In
fact, when your test may affect many different architectures, such "try
jobs" are the only way to do unless you really want to build & test a
branch on a few different OSes.

Once again, this almost always requires some dedicated developers for
watching the tree (Chromium has sheriffs, gardeners, etc.), I'm not sure we
have that for the CPython source.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140125/7f28fd32/attachment.html>

From rdmurray at bitdance.com  Sat Jan 25 16:09:57 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 25 Jan 2014 10:09:57 -0500
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <CAF-Rda_b8N0Xa9Wv5SthUU17p3O15EgYrQEHL5LkzCUcLyKzAw@mail.gmail.com>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <20140125141454.C91B5250058@webabinitio.net>
 <CAF-Rda_b8N0Xa9Wv5SthUU17p3O15EgYrQEHL5LkzCUcLyKzAw@mail.gmail.com>
Message-ID: <20140125150957.A7BFB2500C9@webabinitio.net>

On Sat, 25 Jan 2014 06:35:59 -0800, Eli Bendersky <eliben at gmail.com> wrote:
> On Sat, Jan 25, 2014 at 6:14 AM, R. David Murray <rdmurray at bitdance.com>wrote:
> 
> > On Sat, 25 Jan 2014 05:49:56 -0800, Eli Bendersky <eliben at gmail.com>
> > wrote:
> > > do the latter in Python, which carries a problem we'll probably need to
> > > resolve first - how to know that the bots are green enough. That really
> > > needs human attention.
> >
> > By "that needs human attention", do you mean: dealing with the remaining
> > flaky tests, so that "stable buildbots are green" is a binary decision?
> > We strive for that now, but Nick's proposal would mean we'd have to
> > finally buckle down and complete the work.  I'm sure we'd make some new
> > flaky tests at some point, but in this future they'd become show-stoppers
> > until they were fixed.  I think this would be a good thing, overall :)
> >
> 
> Non-flakiness of bots is a holy grail few projects attain. If your bots are
> consistently green with no flakes, it just means you're not testing enough
> :-)

How does OpenStack do it, then?  I haven't actually looked at Zuul yet,
though it is on my shortlist.

--David

From donald at stufft.io  Sat Jan 25 16:11:04 2014
From: donald at stufft.io (Donald Stufft)
Date: Sat, 25 Jan 2014 10:11:04 -0500
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <20140125150957.A7BFB2500C9@webabinitio.net>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <20140125141454.C91B5250058@webabinitio.net>
 <CAF-Rda_b8N0Xa9Wv5SthUU17p3O15EgYrQEHL5LkzCUcLyKzAw@mail.gmail.com>
 <20140125150957.A7BFB2500C9@webabinitio.net>
Message-ID: <F2D659B0-076E-4F71-B95E-9CD21641F48B@stufft.io>


On Jan 25, 2014, at 10:09 AM, R. David Murray <rdmurray at bitdance.com> wrote:

> On Sat, 25 Jan 2014 06:35:59 -0800, Eli Bendersky <eliben at gmail.com> wrote:
>> On Sat, Jan 25, 2014 at 6:14 AM, R. David Murray <rdmurray at bitdance.com>wrote:
>> 
>>> On Sat, 25 Jan 2014 05:49:56 -0800, Eli Bendersky <eliben at gmail.com>
>>> wrote:
>>>> do the latter in Python, which carries a problem we'll probably need to
>>>> resolve first - how to know that the bots are green enough. That really
>>>> needs human attention.
>>> 
>>> By "that needs human attention", do you mean: dealing with the remaining
>>> flaky tests, so that "stable buildbots are green" is a binary decision?
>>> We strive for that now, but Nick's proposal would mean we'd have to
>>> finally buckle down and complete the work.  I'm sure we'd make some new
>>> flaky tests at some point, but in this future they'd become show-stoppers
>>> until they were fixed.  I think this would be a good thing, overall :)
>>> 
>> 
>> Non-flakiness of bots is a holy grail few projects attain. If your bots are
>> consistently green with no flakes, it just means you're not testing enough
>> :-)
> 
> How does OpenStack do it, then?  I haven't actually looked at Zuul yet,
> though it is on my shortlist.
> 
> --David
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers

Flaky tests have bugs assigned, if a test fails due to a bug you make
a comment on the review saying to reverify with the bug number. It
let?s them track which bugs are causing the most issues with the
gate and such too.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140125/fa79ecad/attachment-0001.sig>

From rdmurray at bitdance.com  Sat Jan 25 16:13:31 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 25 Jan 2014 10:13:31 -0500
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <CAF-Rda-sE6QOjAvFriwVt79W92yfrs3+eomNRT4=n5es7-ZjNw@mail.gmail.com>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <CAKmKYaDv+WDrr2BGj+n3ERG1ooEaG5Y8uh93YsMTsnx2w4pAXg@mail.gmail.com>
 <CAF-Rda-sE6QOjAvFriwVt79W92yfrs3+eomNRT4=n5es7-ZjNw@mail.gmail.com>
Message-ID: <20140125151331.79FDD2500C9@webabinitio.net>

On Sat, 25 Jan 2014 06:59:19 -0800, Eli Bendersky <eliben at gmail.com> wrote:
> On Sat, Jan 25, 2014 at 6:54 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> 
> > On Sat, Jan 25, 2014 at 2:49 PM, Eli Bendersky <eliben at gmail.com> wrote:
> > > Interesting. Chromium has something kind-of similar, named "commit
> > queue",
> > > for developers without actual commit access. Once they get an LGTM, the
> > > thing rolls automatically. In fact, core developers often find it useful
> > too
> > > because the Chromium tree is sometimes closed ("red"). We don't really do
> > > the latter in Python, which carries a problem we'll probably need to
> > resolve
> > > first - how to know that the bots are green enough. That really needs
> > human
> > > attention.
> >
> > Another interesting (and relevant, I think) concept from the Mozilla
> > community is the Try Server, where you can push a work-in-progress
> > patch to see how it does on all the platforms. I.e. it runs all the
> > same tests that build slaves run, but the repository it works against
> > isn't accessible publicly, so you can try your work without breaking
> > the main tree.
> >
> 
> Yep, Chromium has try-jobs too, thanks for reminding me. And in a previous

So do we.  We don't use them much, but that's probably because they are
a relatively new feature of the buildbot farm (the 'custom' builders).

> workplace we had a similar process screwed on top of Jenkins - private test
> runs wherein you provide a branch to CI and the CI tests that branch. In
> fact, when your test may affect many different architectures, such "try
> jobs" are the only way to do unless you really want to build & test a
> branch on a few different OSes.
> 
> Once again, this almost always requires some dedicated developers for
> watching the tree (Chromium has sheriffs, gardeners, etc.), I'm not sure we
> have that for the CPython source.

What do sheriffs and gardeners do?

--David

From ncoghlan at gmail.com  Sat Jan 25 16:40:09 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 26 Jan 2014 01:40:09 +1000
Subject: [python-committers] Status of the Derby,
	and request for another slip
In-Reply-To: <52E3C0FD.5060908@hastings.org>
References: <52E3B787.7070101@hastings.org> <1390656903.2300.0.camel@fsol>
 <52E3C0FD.5060908@hastings.org>
Message-ID: <CADiSq7d9dD7Z34x2zctHbY_hhtFKp8wv9W-NCWwPfLKiD1HwxA@mail.gmail.com>

On 25 January 2014 23:49, Larry Hastings <larry at hastings.org> wrote:
> On 01/25/2014 05:35 AM, Antoine Pitrou wrote:
>
> Stop the Derby. We needn't convert everything for 3.4 (I didn't even
> know that was your goal).
>
>
> Converting everything was my goal at one point.  At this point it is nowhere
> near viable, not the least because there simply isn't enough time.  As
> discussed yesterday on python-dev (subject: "Argument Clinic: what to do
> with builtins with non-standard signatures?"), and today (subject: "New
> policies for the Derby -- please read!"), there are large numbers of
> functions in Python 3.4 that have signatures that can't be expressed by
> inspect.Signature without semantic changes.  Since we can't make those
> changes for 3.4, we can't convert them to Argument Clinic yet.

As per my post to python-dev, the main thing I would like to see
postponed to 3.5 is the varargs support in Argument Clinic. It sounds
like that is worth postponing until 3.5 due to the impact it has on AC
itself, rather than the other issues which need to be delayed due to
their impact on the inspect module and other public APIs.

Basically, I suggest implementing the current bug fixes & minor
features AC patch you're working on, and then calling it done for 3.4,
with only outright bugs in existing conversions to be fixed before
3.5. If it's "I can't convert function X because AC doesn't have
feature Y or suffers from bug Z", then that means function X doesn't
get converted until 3.5. Be ruthless on the "Argument Clinic doesn't
support that yet, so it will have to wait to be converted" :)

I think an extra beta is still a good idea, though - I'd like to get
at least the builtins that are already supported converted, since that
clearly demonstrates the benefits the tool is designed to bring in
reducing the discrepancies between extension code and pure Python
code. That patch is done, it just needs a couple of tests cleaned up
and a review before it can be merged.

Once __text_signature__ is made a public API in Python 3.5, then it
also opens up lots of opportunities for easier introspection support
in other implementations, not just in CPython.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From stefan at bytereef.org  Sat Jan 25 17:11:58 2014
From: stefan at bytereef.org (Stefan Krah)
Date: Sat, 25 Jan 2014 17:11:58 +0100
Subject: [python-committers] Status of the Derby,
 and request for another slip
In-Reply-To: <52E3B787.7070101@hastings.org>
References: <52E3B787.7070101@hastings.org>
Message-ID: <20140125161158.GA8804@sleipnir.bytereef.org>

Larry Hastings <larry at hastings.org> wrote:
> Please vote for either "continue the Derby" (which also means slipping the
> schedule and adding a fourth beta) or "stop the Derby".

I think releasing 3.4 on time is more important than adding internal changes
that most people won't see at all.  So I vote for releasing according to
the schedule.


Stefan Krah




From solipsis at pitrou.net  Sat Jan 25 17:14:56 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 25 Jan 2014 17:14:56 +0100
Subject: [python-committers] Status of the Derby,
 and request for another slip
In-Reply-To: <CADiSq7d9dD7Z34x2zctHbY_hhtFKp8wv9W-NCWwPfLKiD1HwxA@mail.gmail.com>
References: <52E3B787.7070101@hastings.org> <1390656903.2300.0.camel@fsol>
 <52E3C0FD.5060908@hastings.org>
 <CADiSq7d9dD7Z34x2zctHbY_hhtFKp8wv9W-NCWwPfLKiD1HwxA@mail.gmail.com>
Message-ID: <1390666496.2300.3.camel@fsol>


On dim., 2014-01-26 at 01:40 +1000, Nick Coghlan wrote:
> I think an extra beta is still a good idea, though - I'd like to get
> at least the builtins that are already supported converted, since that
> clearly demonstrates the benefits the tool is designed to bring in
> reducing the discrepancies between extension code and pure Python
> code. That patch is done, it just needs a couple of tests cleaned up
> and a review before it can be merged.

I don't think this is a killer feature that would deserve an extension
of the release cycle. The feature freeze period is meant for bug fixing,
not to shoehorn the latest bangs and whistles. Normally the whole Derby
thing should already have waited for 3.5; in hindsight it would probably
have been better to do just that.

Regards

Antoine.



From eliben at gmail.com  Sat Jan 25 18:35:46 2014
From: eliben at gmail.com (Eli Bendersky)
Date: Sat, 25 Jan 2014 09:35:46 -0800
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <20140125151331.79FDD2500C9@webabinitio.net>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <CAKmKYaDv+WDrr2BGj+n3ERG1ooEaG5Y8uh93YsMTsnx2w4pAXg@mail.gmail.com>
 <CAF-Rda-sE6QOjAvFriwVt79W92yfrs3+eomNRT4=n5es7-ZjNw@mail.gmail.com>
 <20140125151331.79FDD2500C9@webabinitio.net>
Message-ID: <CAF-Rda-UPdSeXkqrWTfmfniNTpUx5wNFKMFAEwE4NESw2OS60w@mail.gmail.com>

On Sat, Jan 25, 2014 at 7:13 AM, R. David Murray <rdmurray at bitdance.com>wrote:

> On Sat, 25 Jan 2014 06:59:19 -0800, Eli Bendersky <eliben at gmail.com>
> wrote:
> > On Sat, Jan 25, 2014 at 6:54 AM, Dirkjan Ochtman <dirkjan at ochtman.nl>
> wrote:
> >
> > > On Sat, Jan 25, 2014 at 2:49 PM, Eli Bendersky <eliben at gmail.com>
> wrote:
> > > > Interesting. Chromium has something kind-of similar, named "commit
> > > queue",
> > > > for developers without actual commit access. Once they get an LGTM,
> the
> > > > thing rolls automatically. In fact, core developers often find it
> useful
> > > too
> > > > because the Chromium tree is sometimes closed ("red"). We don't
> really do
> > > > the latter in Python, which carries a problem we'll probably need to
> > > resolve
> > > > first - how to know that the bots are green enough. That really needs
> > > human
> > > > attention.
> > >
> > > Another interesting (and relevant, I think) concept from the Mozilla
> > > community is the Try Server, where you can push a work-in-progress
> > > patch to see how it does on all the platforms. I.e. it runs all the
> > > same tests that build slaves run, but the repository it works against
> > > isn't accessible publicly, so you can try your work without breaking
> > > the main tree.
> > >
> >
> > Yep, Chromium has try-jobs too, thanks for reminding me. And in a
> previous
>
> So do we.  We don't use them much, but that's probably because they are
> a relatively new feature of the buildbot farm (the 'custom' builders).
>
> > workplace we had a similar process screwed on top of Jenkins - private
> test
> > runs wherein you provide a branch to CI and the CI tests that branch. In
> > fact, when your test may affect many different architectures, such "try
> > jobs" are the only way to do unless you really want to build & test a
> > branch on a few different OSes.
> >
> > Once again, this almost always requires some dedicated developers for
> > watching the tree (Chromium has sheriffs, gardeners, etc.), I'm not sure
> we
> > have that for the CPython source.
>
> What do sheriffs and gardeners do?
>

I started replying but then remembered that it's actually all described
here - http://www.chromium.org/developers/tree-sheriffs
If you're interested in such things (build farms, CI, "process") that page
and links from it should provide you with a lot interesting information
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140125/77c5df80/attachment-0001.html>

From solipsis at pitrou.net  Sat Jan 25 19:02:59 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 25 Jan 2014 19:02:59 +0100
Subject: [python-committers] Status of the Derby,
 and request for another slip
In-Reply-To: <1390666496.2300.3.camel@fsol>
References: <52E3B787.7070101@hastings.org> <1390656903.2300.0.camel@fsol>
 <52E3C0FD.5060908@hastings.org>
 <CADiSq7d9dD7Z34x2zctHbY_hhtFKp8wv9W-NCWwPfLKiD1HwxA@mail.gmail.com>
 <1390666496.2300.3.camel@fsol>
Message-ID: <1390672979.2300.4.camel@fsol>

On sam., 2014-01-25 at 17:14 +0100, Antoine Pitrou wrote:
> On dim., 2014-01-26 at 01:40 +1000, Nick Coghlan wrote:
> > I think an extra beta is still a good idea, though - I'd like to get
> > at least the builtins that are already supported converted, since that
> > clearly demonstrates the benefits the tool is designed to bring in
> > reducing the discrepancies between extension code and pure Python
> > code. That patch is done, it just needs a couple of tests cleaned up
> > and a review before it can be merged.
> 
> I don't think this is a killer feature that would deserve an extension
> of the release cycle. The feature freeze period is meant for bug fixing,
> not to shoehorn the latest bangs and whistles.

(perhaps it should be "bells and whistles"; I apologize for the
mismatch)

Regards

Antoine.



From ethan at stoneleaf.us  Sat Jan 25 19:33:44 2014
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sat, 25 Jan 2014 10:33:44 -0800
Subject: [python-committers] Status of the Derby,
 and request for another slip
In-Reply-To: <CADiSq7d9dD7Z34x2zctHbY_hhtFKp8wv9W-NCWwPfLKiD1HwxA@mail.gmail.com>
References: <52E3B787.7070101@hastings.org> <1390656903.2300.0.camel@fsol>
 <52E3C0FD.5060908@hastings.org>
 <CADiSq7d9dD7Z34x2zctHbY_hhtFKp8wv9W-NCWwPfLKiD1HwxA@mail.gmail.com>
Message-ID: <52E40388.3080201@stoneleaf.us>

On 01/25/2014 07:40 AM, Nick Coghlan wrote:
>
> Basically, I suggest implementing the current bug fixes & minor
> features AC patch you're working on, and then calling it done for 3.4,
> with only outright bugs in existing conversions to be fixed before
> 3.5. [...]
>
> I think an extra beta is still a good idea, though - I'd like to get
> at least the builtins that are already supported converted, since that
> clearly demonstrates the benefits the tool is designed to bring in
> reducing the discrepancies between extension code and pure Python
> code. [...]

+1 to what he said.

--
~Ethan~

From solipsis at pitrou.net  Sat Jan 25 20:55:10 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 25 Jan 2014 20:55:10 +0100
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <CAF-Rda_b8N0Xa9Wv5SthUU17p3O15EgYrQEHL5LkzCUcLyKzAw@mail.gmail.com>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <20140125141454.C91B5250058@webabinitio.net>
 <CAF-Rda_b8N0Xa9Wv5SthUU17p3O15EgYrQEHL5LkzCUcLyKzAw@mail.gmail.com>
Message-ID: <1390679710.2300.6.camel@fsol>

On sam., 2014-01-25 at 06:35 -0800, Eli Bendersky wrote:
> On Sat, Jan 25, 2014 at 6:14 AM, R. David Murray
> <rdmurray at bitdance.com> wrote:
>         On Sat, 25 Jan 2014 05:49:56 -0800, Eli Bendersky
>         <eliben at gmail.com> wrote:
>         > do the latter in Python, which carries a problem we'll
>         probably need to
>         > resolve first - how to know that the bots are green enough.
>         That really
>         > needs human attention.
>         
>         
>         By "that needs human attention", do you mean: dealing with the
>         remaining
>         flaky tests, so that "stable buildbots are green" is a binary
>         decision?
>         We strive for that now, but Nick's proposal would mean we'd
>         have to
>         finally buckle down and complete the work.  I'm sure we'd make
>         some new
>         flaky tests at some point, but in this future they'd become
>         show-stoppers
>         until they were fixed.  I think this would be a good thing,
>         overall :)
> 
> 
> Non-flakiness of bots is a holy grail few projects attain. If your
> bots are consistently green with no flakes, it just means you're not
> testing enough :-)

There are certainly statistical ways to workaround the "necessary
flakiness", but that would require someone to sit with a pen and paper a
bit and figure out what the right metrics should be :-)

Regards

Antoine.



From jcea at jcea.es  Sun Jan 26 01:15:52 2014
From: jcea at jcea.es (Jesus Cea)
Date: Sun, 26 Jan 2014 01:15:52 +0100
Subject: [python-committers] Status of the Derby,
 and request for another slip
In-Reply-To: <52E40388.3080201@stoneleaf.us>
References: <52E3B787.7070101@hastings.org> <1390656903.2300.0.camel@fsol>
 <52E3C0FD.5060908@hastings.org>
 <CADiSq7d9dD7Z34x2zctHbY_hhtFKp8wv9W-NCWwPfLKiD1HwxA@mail.gmail.com>
 <52E40388.3080201@stoneleaf.us>
Message-ID: <52E453B8.5090402@jcea.es>

On 25/01/14 19:33, Ethan Furman wrote:
> On 01/25/2014 07:40 AM, Nick Coghlan wrote:
>> 
>> Basically, I suggest implementing the current bug fixes & minor 
>> features AC patch you're working on, and then calling it done
>> for 3.4, with only outright bugs in existing conversions to be
>> fixed before 3.5. [...]
>> 
>> I think an extra beta is still a good idea, though - I'd like to 
>> get at least the builtins that are already supported converted, 
>> since that clearly demonstrates the benefits the tool is designed
>> to bring in reducing the discrepancies between extension code and
>> pure Python code. [...]
> 
> +1 to what he said.

+1. I agree too.

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

From tjreedy at udel.edu  Sun Jan 26 02:20:51 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 25 Jan 2014 20:20:51 -0500
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <1390679710.2300.6.camel@fsol>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <20140125141454.C91B5250058@webabinitio.net>
 <CAF-Rda_b8N0Xa9Wv5SthUU17p3O15EgYrQEHL5LkzCUcLyKzAw@mail.gmail.com>
 <1390679710.2300.6.camel@fsol>
Message-ID: <52E462F3.4010207@udel.edu>

On 1/25/2014 2:55 PM, Antoine Pitrou wrote:
> On sam., 2014-01-25 at 06:35 -0800, Eli Bendersky wrote:
>> On Sat, Jan 25, 2014 at 6:14 AM, R. David Murray
>> <rdmurray at bitdance.com> wrote:
>>          On Sat, 25 Jan 2014 05:49:56 -0800, Eli Bendersky
>>          <eliben at gmail.com> wrote:
>>          > do the latter in Python, which carries a problem we'll
>>          probably need to
>>          > resolve first - how to know that the bots are green enough.
>>          That really
>>          > needs human attention.
>>
>>
>>          By "that needs human attention", do you mean: dealing with the
>>          remaining
>>          flaky tests, so that "stable buildbots are green" is a binary
>>          decision?
>>          We strive for that now, but Nick's proposal would mean we'd
>>          have to
>>          finally buckle down and complete the work.  I'm sure we'd make
>>          some new
>>          flaky tests at some point, but in this future they'd become
>>          show-stoppers
>>          until they were fixed.  I think this would be a good thing,
>>          overall :)
>>
>>
>> Non-flakiness of bots is a holy grail few projects attain. If your
>> bots are consistently green with no flakes, it just means you're not
>> testing enough :-)
>
> There are certainly statistical ways to workaround the "necessary
> flakiness", but that would require someone to sit with a pen and paper a
> bit and figure out what the right metrics should be :-)

If I run the test suit twice and a particular gives different results, 
then it is not purely a test of CPython and not-passing is not 
necessarily a CPython failure. That to mean that the buildbots should 
not be red. Perhaps purple ;-). More seriously, an intermittent timeout 
failure might be recorded as an unexpected or perhaps an 'undesired' 
skip rather than as a test failure. A test failure should indicate that 
CPython needs to be patched, not that the test system, including the 
internet, flaked out.

Terry


From tjreedy at udel.edu  Sun Jan 26 01:33:39 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 25 Jan 2014 19:33:39 -0500
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <CAKmKYaDv+WDrr2BGj+n3ERG1ooEaG5Y8uh93YsMTsnx2w4pAXg@mail.gmail.com>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <CAKmKYaDv+WDrr2BGj+n3ERG1ooEaG5Y8uh93YsMTsnx2w4pAXg@mail.gmail.com>
Message-ID: <52E457E3.3020507@udel.edu>

On 1/25/2014 9:54 AM, Dirkjan Ochtman wrote:
> On Sat, Jan 25, 2014 at 2:49 PM, Eli Bendersky <eliben at gmail.com> wrote:
>> Interesting. Chromium has something kind-of similar, named "commit queue",
>> for developers without actual commit access. Once they get an LGTM, the
>> thing rolls automatically. In fact, core developers often find it useful too
>> because the Chromium tree is sometimes closed ("red"). We don't really do
>> the latter in Python, which carries a problem we'll probably need to resolve
>> first - how to know that the bots are green enough. That really needs human
>> attention.
>
> Another interesting (and relevant, I think) concept from the Mozilla
> community is the Try Server, where you can push a work-in-progress
> patch to see how it does on all the platforms. I.e. it runs all the
> same tests that build slaves run, but the repository it works against
> isn't accessible publicly, so you can try your work without breaking
> the main tree.

What would be very useful would be the ability to run a single test case 
function for a bug report on 2.7, 3.3, and 3.4 on mac, linux, and window 
in order to delineate the scope of an issue. Right now, the op or first 
developer mush hope that people with different systems will show up and 
run the bug test on the three branches.

Terry



From ncoghlan at gmail.com  Sun Jan 26 12:53:55 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 26 Jan 2014 21:53:55 +1000
Subject: [python-committers] Status of the Derby,
	and request for another slip
In-Reply-To: <1390666496.2300.3.camel@fsol>
References: <52E3B787.7070101@hastings.org> <1390656903.2300.0.camel@fsol>
 <52E3C0FD.5060908@hastings.org>
 <CADiSq7d9dD7Z34x2zctHbY_hhtFKp8wv9W-NCWwPfLKiD1HwxA@mail.gmail.com>
 <1390666496.2300.3.camel@fsol>
Message-ID: <CADiSq7e=gOm+-5_ApKiGKmRPb6v6uSWMRkTLppGwYCLDWS5LRA@mail.gmail.com>

On 26 January 2014 02:14, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> On dim., 2014-01-26 at 01:40 +1000, Nick Coghlan wrote:
>> I think an extra beta is still a good idea, though - I'd like to get
>> at least the builtins that are already supported converted, since that
>> clearly demonstrates the benefits the tool is designed to bring in
>> reducing the discrepancies between extension code and pure Python
>> code. That patch is done, it just needs a couple of tests cleaned up
>> and a review before it can be merged.
>
> I don't think this is a killer feature that would deserve an extension
> of the release cycle. The feature freeze period is meant for bug fixing,
> not to shoehorn the latest bangs and whistles. Normally the whole Derby
> thing should already have waited for 3.5; in hindsight it would probably
> have been better to do just that.

This is a fair point - I think it would also be reasonable (and quite
possibly preferable) to say "no more clinic conversions for 3.4",
including my almost complete patch for the builtins and any other
almost complete patches. The existing conversions would stay, but our
focus for the remainder of the release cycle could then return to bug
fixes for existing changes (including any genuine bugs in AC for the
already converted extension modules.

I was OK with trying the conversion within the beta period, but I
think the experience of the past couple of weeks has shown that it was
higher impact than we first thought, and that there were more gaps in
the current capabilities of both argument clinic and the inspect
module than we first thought.

By postponing further conversions, we can refocus on the 3.4 release
in the near term, and then update PEP 457 for 3.5 based on our
experience in attempting these conversions for 3.4.

It wouldn't be the first time where a change we've made in one release
has mostly been about setting up a benefit for end users that wasn't
fully realised until the next release (__qualname__ in 3.3 leading to
unbound method pickling support in 3.4 is the main recent example that
comes to mind, but PEP 451 certainly has follow on work that will
continue into 3.5, and the underlying goal of adding
functools.singledispatch was actually to convert the pprint module to
use it, which now won't be happening until 3.5 at the earliest).

While part of my brain is still saying "but we're so close...", I
think I'm coming around to the view that Antoine is right and we
should just stop the Derby and focus on getting the 3.4 release
candidate ready for February 9. It's disappointing, definitely, but
it's also the most responsible course of action available.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From storchaka at gmail.com  Sun Jan 26 13:57:24 2014
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sun, 26 Jan 2014 14:57:24 +0200
Subject: [python-committers] Status of the Derby,
	and request for another slip
In-Reply-To: <1390666496.2300.3.camel@fsol>
References: <52E3B787.7070101@hastings.org> <1390656903.2300.0.camel@fsol>
 <52E3C0FD.5060908@hastings.org>
 <CADiSq7d9dD7Z34x2zctHbY_hhtFKp8wv9W-NCWwPfLKiD1HwxA@mail.gmail.com>
 <1390666496.2300.3.camel@fsol>
Message-ID: <lc30n8$m6i$1@ger.gmane.org>

25.01.14 18:14, Antoine Pitrou ???????(??):
> I don't think this is a killer feature that would deserve an extension
> of the release cycle. The feature freeze period is meant for bug fixing,
> not to shoehorn the latest bangs and whistles. Normally the whole Derby
> thing should already have waited for 3.5; in hindsight it would probably
> have been better to do just that.

There is at least one benefit from Derby: it have exhibited many errors 
in already clinicalized code and in pydoc and inspect modules (and in 
Argument Clinic itself).


From taleinat at gmail.com  Sun Jan 26 14:15:34 2014
From: taleinat at gmail.com (Tal Einat)
Date: Sun, 26 Jan 2014 15:15:34 +0200
Subject: [python-committers] Status of the Derby,
	and request for another slip
In-Reply-To: <52E3B787.7070101@hastings.org>
References: <52E3B787.7070101@hastings.org>
Message-ID: <CALWZvp5h+eRZyWucUDY0Bhg5ddRqVm5Q6AQCobPHSz1RM0FpMQ@mail.gmail.com>

On Sat, Jan 25, 2014 at 3:09 PM, Larry Hastings <larry at hastings.org> wrote:
> To be honest I have absolutely no idea what % of files have been converted
> so far.  Figuring it out would use time that would be better spent catching
> up on my to-do list.

Of the 22 Derby issues:
* 2 have been closed: 20133 (audioop) and 20151 (binascci)
* 7 are practically done
* 6 are about half done
* 7 still need most (or all) of the work done

So I'd say that the derby is about half finished, not taking into
account the required changes and improvements to clinic.py and
additional overhead and unexpected problems.

Details on the 20 open Derby issues:

Apparently or nearly completed Derby issues (7):
* 20148: _sre
* 20168: tkinter
* 20172: Windows stuff
* 20173: codecs, md5, sha*
* 20174: socket (+ functools)
* 20178: ctypes, sqlite (+ _curses_cpanel.c)
* 20180: collections, itertools, random, unicode, stringlib (+
xxlimited.c, xxmodule.c, xxsutype.c)

Approximately half completed Derby issues (6):
* 20152: cmath, multibytecodec, array, pyexpat, fcntl, pwd, spwd, grp
* 20159: etree, PC/_msc.c, PC/bdist_wininst/install.c
* 20171: curses (117 sites!)
* 20177: time, datetime
* 20182: select, signal, zlib, sys (+ _hashopenssl.c)
* 20185: type, long, list, float, resource, thread, bz2, bisect,
marshal, exceptions, nis, gc, warnings, crypt

Derby issues not started or barely started (7):
* 20170: posix (137 sites!)
* 20175: io (+ multiprocessing)
* 20179: ssl, overlapped (+ bytesobject.c, bytes_methods.c)
* 20181: bytearray, parser, unicodedata, readline
* 20183: mmap, locale, zipimport, ossaudiodev, _testbuffer.c, struct
* 20184: bltinmodule, faulthandler, pickle, lzma, termios, syslog,
dbm, gdbm, json
* 20186: tuple, memory, descr, complex, operator, opcode, lsprof,
heapq, weakref, struct, range, object,
         modules, func, file, enum, code, bool, symtable, math,
_tracemalloc.c, io, csv


> Please vote for either "continue the Derby" (which also means slipping the
> schedule and adding a fourth beta) or "stop the Derby".

Having worked intensively on the Derby for over a week, I feel an urge
to see it through soon. The least we could do is to stop adding
features to clinic.py, only fixing bugs; convert everything that is
possible to convert now and mark everything else appropriately; and
leave tying up the loose ends for 3.5.

However, I'm not a "core dev" and can certainly see the problem with
pushing back the release date again, with significant uncertainty
whether even that will be enough time. Therefore, I'm not voting.

I can, however, promise to convert a great deal more code in the next
two weeks if it is decided to push the release.

- Tal

From ncoghlan at gmail.com  Sun Jan 26 14:18:55 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 26 Jan 2014 23:18:55 +1000
Subject: [python-committers] Status of the Derby,
	and request for another slip
In-Reply-To: <lc30n8$m6i$1@ger.gmane.org>
References: <52E3B787.7070101@hastings.org> <1390656903.2300.0.camel@fsol>
 <52E3C0FD.5060908@hastings.org>
 <CADiSq7d9dD7Z34x2zctHbY_hhtFKp8wv9W-NCWwPfLKiD1HwxA@mail.gmail.com>
 <1390666496.2300.3.camel@fsol> <lc30n8$m6i$1@ger.gmane.org>
Message-ID: <CADiSq7cmujsKxAyoNw7WwhiFdb=ToR0XXbLKLr5JnYAerzq4Sw@mail.gmail.com>

On 26 January 2014 22:57, Serhiy Storchaka <storchaka at gmail.com> wrote:
> 25.01.14 18:14, Antoine Pitrou ???????(??):
>
>> I don't think this is a killer feature that would deserve an extension
>> of the release cycle. The feature freeze period is meant for bug fixing,
>> not to shoehorn the latest bangs and whistles. Normally the whole Derby
>> thing should already have waited for 3.5; in hindsight it would probably
>> have been better to do just that.
>
>
> There is at least one benefit from Derby: it have exhibited many errors in
> already clinicalized code and in pydoc and inspect modules (and in Argument
> Clinic itself).

Right, I think the Derby provided valuable experience, but I also now
think Antoine's right that we should postponing any further
conversions until 3.5, and focus on cleaning up both the existing
conversions, as well as the technical details of working with Argument
Clinic.

Specifically, I think we want to have the following in place for 3.4:

1. Larry's patch to make the Argument Clinic signature markers more
robust (http://bugs.python.org/issue20326)
2. Generating separate clinic files by default
3. Integrating clinic into "make patchcheck", similar to the
reindent.py integration (http://bugs.python.org/issue20264)
4. Adding a commit hook that ensures clinic files have been
regenerated prior to commit/push

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Sun Jan 26 14:27:00 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 26 Jan 2014 23:27:00 +1000
Subject: [python-committers] Status of the Derby,
	and request for another slip
In-Reply-To: <CALWZvp5h+eRZyWucUDY0Bhg5ddRqVm5Q6AQCobPHSz1RM0FpMQ@mail.gmail.com>
References: <52E3B787.7070101@hastings.org>
 <CALWZvp5h+eRZyWucUDY0Bhg5ddRqVm5Q6AQCobPHSz1RM0FpMQ@mail.gmail.com>
Message-ID: <CADiSq7eVJ7WXUj4x15hDcy+k3nQwr0sHzpkACe-5Z9KSxkqKGg@mail.gmail.com>

On 26 January 2014 23:15, Tal Einat <taleinat at gmail.com> wrote:
>
> Having worked intensively on the Derby for over a week, I feel an urge
> to see it through soon. The least we could do is to stop adding
> features to clinic.py, only fixing bugs; convert everything that is
> possible to convert now and mark everything else appropriately; and
> leave tying up the loose ends for 3.5.

Actually, I think one thing we need to consider is when Larry plans to
make the maintenance branch for 3.4. I believe historically, we have
done that with the first release candidate, so the current schedule
would allow clinic conversions for 3.5 to resume in just couple of
weeks time. The difference between the beta and RC period is that only
critical regressions discovered in the RC are considered for inclusion
- even normal bug fixing is typically postponed until after the
release at that point. Any fixes incorporated during that period
typically involve at least three core devs (release manager to say yes
to including the fix, one to write a patch, another to review it).

Cheers,
Nick.

P.S. There are a couple of builtin docstring fixes I now plan to apply
directly, since I won't be converting those to Argument Clinic for 3.4
after all.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From raymond.hettinger at gmail.com  Sun Jan 26 16:14:20 2014
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sun, 26 Jan 2014 07:14:20 -0800
Subject: [python-committers] Status of the Derby,
	and request for another slip
In-Reply-To: <52E3B787.7070101@hastings.org>
References: <52E3B787.7070101@hastings.org>
Message-ID: <0AB4493A-CF53-41FC-9E3C-C8C18D2FF58F@gmail.com>


On Jan 25, 2014, at 5:09 AM, Larry Hastings <larry at hastings.org> wrote:

> I'd like to extend the Derby by two more weeks and add a fourth beta.

There's no harm in adding a fourth beta and if it improves the release
you should probably do so.  We don't owe anyone a particular release
date and AFAICT no one is holding their breath.  The release date is
a self-imposed deadline.

That said, further 3.4 work on the Argument Clinic ought to be aimed
at improving the quality of the work so far, rather than digging in deeper.

When it comes to conceptual flaws, the important thing is to make sure
that the 3.4 release doesn't lock you in to a decision you're going to 
want to change later.

FWIW, several lines of the Zen of Python seem to be relevant
to this discussion.


Raymond


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140126/4285d383/attachment.html>

From rdmurray at bitdance.com  Sun Jan 26 16:51:51 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 26 Jan 2014 10:51:51 -0500
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <CAF-Rda-UPdSeXkqrWTfmfniNTpUx5wNFKMFAEwE4NESw2OS60w@mail.gmail.com>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <CAKmKYaDv+WDrr2BGj+n3ERG1ooEaG5Y8uh93YsMTsnx2w4pAXg@mail.gmail.com>
 <CAF-Rda-sE6QOjAvFriwVt79W92yfrs3+eomNRT4=n5es7-ZjNw@mail.gmail.com>
 <20140125151331.79FDD2500C9@webabinitio.net>
 <CAF-Rda-UPdSeXkqrWTfmfniNTpUx5wNFKMFAEwE4NESw2OS60w@mail.gmail.com>
Message-ID: <20140126155151.C62B8250489@webabinitio.net>

On Sat, 25 Jan 2014 09:35:46 -0800, Eli Bendersky <eliben at gmail.com> wrote:
> On Sat, Jan 25, 2014 at 7:13 AM, R. David Murray <rdmurray at bitdance.com>wrote:
> 
> > On Sat, 25 Jan 2014 06:59:19 -0800, Eli Bendersky <eliben at gmail.com>
> > wrote:
> > > workplace we had a similar process screwed on top of Jenkins - private
> > test
> > > runs wherein you provide a branch to CI and the CI tests that branch. In
> > > fact, when your test may affect many different architectures, such "try
> > > jobs" are the only way to do unless you really want to build & test a
> > > branch on a few different OSes.
> > >
> > > Once again, this almost always requires some dedicated developers for
> > > watching the tree (Chromium has sheriffs, gardeners, etc.), I'm not sure
> > we
> > > have that for the CPython source.
> >
> > What do sheriffs and gardeners do?
> >
> 
> I started replying but then remembered that it's actually all described
> here - http://www.chromium.org/developers/tree-sheriffs
> If you're interested in such things (build farms, CI, "process") that page
> and links from it should provide you with a lot interesting information

I didn't read past the first part of that, where it said "closes,
throttles and opens the tree" and "tracks down people responsible
for breakage".  This is emphatically *not* the Zuul model, from
what Nick has said.  In Zull, patches don't get *in* to the tree
unless the buildbots are all green with the patch applied (so, no
unit-test-discovered "breakage" can occur in the tree).

Donald answered my question about flaky tests: if a flaky test causes
the failure, whoever is trying to get it integrated can trigger a new
run (referencing the bug that documents the flaky test), and if that
run passes, the patch gets committed.

This makes much more sense to me than the 'sheriff' approach, which is
essentially what we have now, albeit with no formally appointed sheriffs,
and no tree closures.

--David

From donald at stufft.io  Sun Jan 26 17:01:06 2014
From: donald at stufft.io (Donald Stufft)
Date: Sun, 26 Jan 2014 11:01:06 -0500
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <20140126155151.C62B8250489@webabinitio.net>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <CAKmKYaDv+WDrr2BGj+n3ERG1ooEaG5Y8uh93YsMTsnx2w4pAXg@mail.gmail.com>
 <CAF-Rda-sE6QOjAvFriwVt79W92yfrs3+eomNRT4=n5es7-ZjNw@mail.gmail.com>
 <20140125151331.79FDD2500C9@webabinitio.net>
 <CAF-Rda-UPdSeXkqrWTfmfniNTpUx5wNFKMFAEwE4NESw2OS60w@mail.gmail.com>
 <20140126155151.C62B8250489@webabinitio.net>
Message-ID: <3C7D39BD-790F-4EA3-8585-F8815DE88FA3@stufft.io>

For the record, I find the way Openstack does it very awesome, even if
I?m not a huge fan of gerrit itself. It?s also nice that repeated runs make
you file a bug for flaky tests and reference it because you can see which
bugs are causing the most heart ache in the test suite as far as flakiness
goes. This gives you a sort of impact ordered list of things to fix up.

On Jan 26, 2014, at 10:51 AM, R. David Murray <rdmurray at bitdance.com> wrote:

> On Sat, 25 Jan 2014 09:35:46 -0800, Eli Bendersky <eliben at gmail.com> wrote:
>> On Sat, Jan 25, 2014 at 7:13 AM, R. David Murray <rdmurray at bitdance.com>wrote:
>> 
>>> On Sat, 25 Jan 2014 06:59:19 -0800, Eli Bendersky <eliben at gmail.com>
>>> wrote:
>>>> workplace we had a similar process screwed on top of Jenkins - private
>>> test
>>>> runs wherein you provide a branch to CI and the CI tests that branch. In
>>>> fact, when your test may affect many different architectures, such "try
>>>> jobs" are the only way to do unless you really want to build & test a
>>>> branch on a few different OSes.
>>>> 
>>>> Once again, this almost always requires some dedicated developers for
>>>> watching the tree (Chromium has sheriffs, gardeners, etc.), I'm not sure
>>> we
>>>> have that for the CPython source.
>>> 
>>> What do sheriffs and gardeners do?
>>> 
>> 
>> I started replying but then remembered that it's actually all described
>> here - http://www.chromium.org/developers/tree-sheriffs
>> If you're interested in such things (build farms, CI, "process") that page
>> and links from it should provide you with a lot interesting information
> 
> I didn't read past the first part of that, where it said "closes,
> throttles and opens the tree" and "tracks down people responsible
> for breakage".  This is emphatically *not* the Zuul model, from
> what Nick has said.  In Zull, patches don't get *in* to the tree
> unless the buildbots are all green with the patch applied (so, no
> unit-test-discovered "breakage" can occur in the tree).
> 
> Donald answered my question about flaky tests: if a flaky test causes
> the failure, whoever is trying to get it integrated can trigger a new
> run (referencing the bug that documents the flaky test), and if that
> run passes, the patch gets committed.
> 
> This makes much more sense to me than the 'sheriff' approach, which is
> essentially what we have now, albeit with no formally appointed sheriffs,
> and no tree closures.
> 
> --David
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140126/79b48e9e/attachment.sig>

From doko at ubuntu.com  Sun Jan 26 18:53:57 2014
From: doko at ubuntu.com (Matthias Klose)
Date: Sun, 26 Jan 2014 18:53:57 +0100
Subject: [python-committers] Status of the Derby,
 and request for another slip
In-Reply-To: <52E3B787.7070101@hastings.org>
References: <52E3B787.7070101@hastings.org>
Message-ID: <52E54BB5.5050104@ubuntu.com>

Am 25.01.2014 14:09, schrieb Larry Hastings:
> I'd like to extend the Derby by two more weeks and add a fourth beta.

In the past I did like the way how accurate the releases were planned and didn't
slip at all, or only slip for a few days.

This may sound a bit selfish, but a few Ubuntu developers do run their own Derby
to use 3.4 as the default Python3 version for the next Ubuntu release in April,
so a timely release would be appreciated ;)

> Please vote for either "continue the Derby" (which also means slipping the
> schedule and adding a fourth beta) or "stop the Derby".

that would be a biased -1 from my side

  Matthias

PS: For those interested, Ubuntu currently has the 3.4 beta as an alternative
version built.  I hope to have better results next week of what will break with
3.4 as the default python3 version.


From barry at python.org  Sun Jan 26 22:49:49 2014
From: barry at python.org (Barry Warsaw)
Date: Sun, 26 Jan 2014 13:49:49 -0800
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
Message-ID: <20140126134949.7e1468d3@anarchist>

On Jan 25, 2014, at 03:51 PM, Nick Coghlan wrote:

>Rather than leaving my ideas undocumented until the language summit in
>April, I wrote up what I see as the critical issues in our current
>workflow and how I believe Zuul could help us resolve them as a PEP:
>http://www.python.org/dev/peps/pep-0462/

Without consideration of the amount of work involved and all the devilish
details, I am totally in favor of this plan.  JFDI. :)

-Barry

From eliben at gmail.com  Sun Jan 26 22:59:38 2014
From: eliben at gmail.com (Eli Bendersky)
Date: Sun, 26 Jan 2014 13:59:38 -0800
Subject: [python-committers] Status of the Derby,
	and request for another slip
In-Reply-To: <52E54BB5.5050104@ubuntu.com>
References: <52E3B787.7070101@hastings.org> <52E54BB5.5050104@ubuntu.com>
Message-ID: <CAF-Rda-za44Sgh4Bk_pP0oRmt6Tz1wifvLo2PQzY2GkWKYw8ew@mail.gmail.com>

On Sun, Jan 26, 2014 at 9:53 AM, Matthias Klose <doko at ubuntu.com> wrote:

> Am 25.01.2014 14:09, schrieb Larry Hastings:
> > I'd like to extend the Derby by two more weeks and add a fourth beta.
>
> In the past I did like the way how accurate the releases were planned and
> didn't
> slip at all, or only slip for a few days.
>
> This may sound a bit selfish, but a few Ubuntu developers do run their own
> Derby
> to use 3.4 as the default Python3 version for the next Ubuntu release in
> April,
> so a timely release would be appreciated ;)
>

This actually sounds like a real and interesting reason to have stable
Python 3.4 out in march. Ubuntu 14.04 is a LTS, which makes it an important
version for corporate distributions.

In addition, other major projects align themselves with released versions
of Python. For example Django - I would love to see trunk Django formally
support Python 3.4 ASAP.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140126/91a81b08/attachment.html>

From barry at python.org  Sun Jan 26 23:16:44 2014
From: barry at python.org (Barry Warsaw)
Date: Sun, 26 Jan 2014 14:16:44 -0800
Subject: [python-committers] Status of the Derby,
 and request for another slip
In-Reply-To: <CAF-Rda-za44Sgh4Bk_pP0oRmt6Tz1wifvLo2PQzY2GkWKYw8ew@mail.gmail.com>
References: <52E3B787.7070101@hastings.org> <52E54BB5.5050104@ubuntu.com>
 <CAF-Rda-za44Sgh4Bk_pP0oRmt6Tz1wifvLo2PQzY2GkWKYw8ew@mail.gmail.com>
Message-ID: <20140126141644.5d406630@anarchist>

On Jan 26, 2014, at 01:59 PM, Eli Bendersky wrote:

>This actually sounds like a real and interesting reason to have stable
>Python 3.4 out in march. Ubuntu 14.04 is a LTS, which makes it an important
>version for corporate distributions.

Ubuntu 14.04 feature freeze is Feb 20, with beta 1 coming on Feb 27, so I
think we have to make a hard decision about whether Python 3.4 will be the
default before then (actually, Matthias and I will discuss it this week).

If we go with 3.4 as default, then 14.04 final beta is March 27th.  Python
3.4's final release is currently schedule for March 16, but that doesn't
include the proposed additional beta.  Pushing everything back a week means
the schedule is quite tight, so we may have to plan on doing an SRU (stable
release upgrade) to the final Python 3.4.  That's not ideal though because it
means a lot of users may not get it (if they don't upgrade), and most probably
won't see it until 14.04.1 is released some time later.

The closer Python 3.4 can stick to the March 16th release, the better.

-Barry

From guido at python.org  Sun Jan 26 23:18:52 2014
From: guido at python.org (Guido van Rossum)
Date: Sun, 26 Jan 2014 14:18:52 -0800
Subject: [python-committers] Status of the Derby,
	and request for another slip
In-Reply-To: <20140126141644.5d406630@anarchist>
References: <52E3B787.7070101@hastings.org> <52E54BB5.5050104@ubuntu.com>
 <CAF-Rda-za44Sgh4Bk_pP0oRmt6Tz1wifvLo2PQzY2GkWKYw8ew@mail.gmail.com>
 <20140126141644.5d406630@anarchist>
Message-ID: <CAP7+vJKKMXsY6Lq2QUZJYLhsqbbXaFot_pgZ5rBBC5kxSVcnMg@mail.gmail.com>

On Sun, Jan 26, 2014 at 2:16 PM, Barry Warsaw <barry at python.org> wrote:

> On Jan 26, 2014, at 01:59 PM, Eli Bendersky wrote:
>
> >This actually sounds like a real and interesting reason to have stable
> >Python 3.4 out in march. Ubuntu 14.04 is a LTS, which makes it an
> important
> >version for corporate distributions.
>
> Ubuntu 14.04 feature freeze is Feb 20, with beta 1 coming on Feb 27, so I
> think we have to make a hard decision about whether Python 3.4 will be the
> default before then (actually, Matthias and I will discuss it this week).
>
> If we go with 3.4 as default, then 14.04 final beta is March 27th.  Python
> 3.4's final release is currently schedule for March 16, but that doesn't
> include the proposed additional beta.  Pushing everything back a week means
> the schedule is quite tight, so we may have to plan on doing an SRU (stable
> release upgrade) to the final Python 3.4.  That's not ideal though because
> it
> means a lot of users may not get it (if they don't upgrade), and most
> probably
> won't see it until 14.04.1 is released some time later.
>
> The closer Python 3.4 can stick to the March 16th release, the better.
>

Yes. That's the whole point of time-based releases. Please stick to the
plan. We've already slipped once. Perfection is not required.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140126/6774b205/attachment.html>

From tjreedy at udel.edu  Sun Jan 26 23:35:45 2014
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 26 Jan 2014 17:35:45 -0500
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <20140126155151.C62B8250489@webabinitio.net>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <CAKmKYaDv+WDrr2BGj+n3ERG1ooEaG5Y8uh93YsMTsnx2w4pAXg@mail.gmail.com>
 <CAF-Rda-sE6QOjAvFriwVt79W92yfrs3+eomNRT4=n5es7-ZjNw@mail.gmail.com>
 <20140125151331.79FDD2500C9@webabinitio.net>
 <CAF-Rda-UPdSeXkqrWTfmfniNTpUx5wNFKMFAEwE4NESw2OS60w@mail.gmail.com>
 <20140126155151.C62B8250489@webabinitio.net>
Message-ID: <52E58DC1.2010907@udel.edu>

I suggest that we start with automating doc-only patches.

1. The need is great. The backlog of Documentation patches is nearly 
700. I am sure that the high overhead per patch has something to do with 
this. (I suspect I would do more if allowed to fix multiple issues in 
one patch, to spread the overhead.) It has been written somewhere that 
there is a set of doc maintainers that will turn suggestions into 
patches, if necessary, and apply them. On a day-to-day basis, that set 
seems to be empty now.

2. A doc patch queue seems slightly easier. Rietveld integration would 
not have to be part of the first cut. It should also be less impactful. 
It would not need exclusive access to the repository except for a short 
period each day (pick the least used hour of the day). On startup, the 
system could post a message to this list "Auto doc patching started. 
Repository closed." A 'repository open' message would follow when done. 
At other times, patches could be pre-tested on a clone and only passing 
patches queued for a final test and push.

Terry


From larry at hastings.org  Mon Jan 27 01:29:26 2014
From: larry at hastings.org (Larry Hastings)
Date: Sun, 26 Jan 2014 16:29:26 -0800
Subject: [python-committers] Status of the Derby,
 and request for another slip
In-Reply-To: <CAP7+vJKKMXsY6Lq2QUZJYLhsqbbXaFot_pgZ5rBBC5kxSVcnMg@mail.gmail.com>
References: <52E3B787.7070101@hastings.org> <52E54BB5.5050104@ubuntu.com>
 <CAF-Rda-za44Sgh4Bk_pP0oRmt6Tz1wifvLo2PQzY2GkWKYw8ew@mail.gmail.com>
 <20140126141644.5d406630@anarchist>
 <CAP7+vJKKMXsY6Lq2QUZJYLhsqbbXaFot_pgZ5rBBC5kxSVcnMg@mail.gmail.com>
Message-ID: <52E5A866.60806@hastings.org>


On 01/26/2014 02:18 PM, Guido van Rossum wrote:
> On Sun, Jan 26, 2014 at 2:16 PM, Barry Warsaw <barry at python.org 
> <mailto:barry at python.org>> wrote:
>
>     The closer Python 3.4 can stick to the March 16th release, the better.
>
>
> Yes. That's the whole point of time-based releases. Please stick to 
> the plan. We've already slipped once. Perfection is not required.

The trend was clear even before Guido weighed in.  But that certainly 
clinches it.

I've just posted to python-dev announcing that the Derby is closing.  
I'm not cutting it off instantly, in case there are people with 
partially-complete patches that haven't been posted to the issue 
tracker.  (I know of one such person: me.)  So I'm giving them a little 
time to submit their patches, Wednesday morning at midnight.

This'll be nice for me as I could use a break from Argument Clinic, and 
the Derby in particular.


And, in hindsight, perfection was never on the table ;-)


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140126/4e61e3fa/attachment-0001.html>

From ncoghlan at gmail.com  Mon Jan 27 03:15:24 2014
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 27 Jan 2014 12:15:24 +1000
Subject: [python-committers] PEP 462: Workflow automation for CPython
In-Reply-To: <3C7D39BD-790F-4EA3-8585-F8815DE88FA3@stufft.io>
References: <CADiSq7d+zUQiDcAY+fBWOcYHCSxwC63rHsuoeK1P+GgfOsmx+g@mail.gmail.com>
 <CAF-Rda-E8vQ0LdxiN8-_PUVywf_wBN34J69dz5Ed=QSTkZ0uiw@mail.gmail.com>
 <CAKmKYaDv+WDrr2BGj+n3ERG1ooEaG5Y8uh93YsMTsnx2w4pAXg@mail.gmail.com>
 <CAF-Rda-sE6QOjAvFriwVt79W92yfrs3+eomNRT4=n5es7-ZjNw@mail.gmail.com>
 <20140125151331.79FDD2500C9@webabinitio.net>
 <CAF-Rda-UPdSeXkqrWTfmfniNTpUx5wNFKMFAEwE4NESw2OS60w@mail.gmail.com>
 <20140126155151.C62B8250489@webabinitio.net>
 <3C7D39BD-790F-4EA3-8585-F8815DE88FA3@stufft.io>
Message-ID: <CADiSq7c_6SsePWkNA8skLSKvAdeK1TZyCdhV7Nph4yLXaJRjAg@mail.gmail.com>

On 27 January 2014 02:01, Donald Stufft <donald at stufft.io> wrote:
> For the record, I find the way Openstack does it very awesome, even if
> I?m not a huge fan of gerrit itself. It?s also nice that repeated runs make
> you file a bug for flaky tests and reference it because you can see which
> bugs are causing the most heart ache in the test suite as far as flakiness
> goes. This gives you a sort of impact ordered list of things to fix up.

Elastic recheck (http://status.openstack.org/elastic-recheck/) is also
spectacularly impressive, and something I would love to have for
CPython. However, baby steps :)

Cheers,
Nick.

P.S. https://www.youtube.com/watch?v=xGLMe2dyx6k goes into more detail
on how Elastic recheck works

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From larry at hastings.org  Mon Jan 27 07:21:51 2014
From: larry at hastings.org (Larry Hastings)
Date: Sun, 26 Jan 2014 22:21:51 -0800
Subject: [python-committers] [RELEASED] Python 3.4.0b3
Message-ID: <52E5FAFF.1080901@hastings.org>



On behalf of the Python development team, I'm quite pleased to announce
the third beta release of Python 3.4.

This is a preview release, and its use is not recommended for
production settings.

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

Python 3.4 is now in "feature freeze", meaning that no new features will be
added.  The final release is projected for mid-March 2014.


To download Python 3.4.0b3 visit:

     http://www.python.org/download/releases/3.4.0/


Please consider trying Python 3.4.0b3 with your code and reporting any
new 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)

From georg at python.org  Mon Jan 27 08:36:46 2014
From: georg at python.org (Georg Brandl)
Date: Mon, 27 Jan 2014 08:36:46 +0100
Subject: [python-committers] [RELEASED] Python 3.3.4 release candidate 1
Message-ID: <52E60C8E.1050908@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On behalf of the Python development team, I'm reasonably happy to announce the
Python 3.3.4 release candidate 1.

Python 3.3.4 includes several security fixes and over 120 bug fixes compared to
the Python 3.3.3 release.

This release fully supports OS X 10.9 Mavericks.  In particular, this release
fixes an issue that could cause previous versions of Python to crash when typing
in interactive mode on OS X 10.9.

Python 3.3 includes a range of improvements of the 3.x series, as well as easier
porting between 2.x and 3.x.  In total, almost 500 API items are new or improved
in Python 3.3.  For a more extensive list of changes in the 3.3 series, see

    http://docs.python.org/3.3/whatsnew/3.3.html

and for the detailed changelog of 3.3.4, see

    http://docs.python.org/3.3/whatsnew/changelog.html

To download Python 3.3.4 rc1 visit:

    http://www.python.org/download/releases/3.3.4/

This is a preview release, please report any bugs to

     http://bugs.python.org/

The final version is scheduled to be released in two weeks' time, on or about
the 10th of February.

Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlLmDI4ACgkQN9GcIYhpnLAr6wCePRbHF80k5goV4RUDBA5FfkwF
rLUAnRg0RpL/b6apv+Dt2/sgnUd3hTPA
=Z4Ss
-----END PGP SIGNATURE-----

From yselivanov.ml at gmail.com  Mon Jan 27 20:52:16 2014
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Mon, 27 Jan 2014 14:52:16 -0500
Subject: [python-committers] Code review tool (rietveld) bug
Message-ID: <52E6B8F0.9050908@gmail.com>

Hello,

I'm having difficulty with replying to a message in rietveld.

Here's a screenshot of the exception: http://goo.gl/70iQ5v
(AttributeError at /review/20356/publish)

Is this a known issue? Maybe I'm doing something wrong?

Yury

From solipsis at pitrou.net  Mon Jan 27 20:56:11 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 27 Jan 2014 20:56:11 +0100
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <52E6B8F0.9050908@gmail.com>
References: <52E6B8F0.9050908@gmail.com>
Message-ID: <1390852571.2289.1.camel@fsol>

On lun., 2014-01-27 at 14:52 -0500, Yury Selivanov wrote:
> Hello,
> 
> I'm having difficulty with replying to a message in rietveld.
> 
> Here's a screenshot of the exception: http://goo.gl/70iQ5v
> (AttributeError at /review/20356/publish)
> 
> Is this a known issue? Maybe I'm doing something wrong?

Have you tried more than once? I've experienced sporadic errors at
times.

Regards

Antoine.



From andrew.svetlov at gmail.com  Mon Jan 27 20:58:23 2014
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Mon, 27 Jan 2014 21:58:23 +0200
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <52E6B8F0.9050908@gmail.com>
References: <52E6B8F0.9050908@gmail.com>
Message-ID: <CAL3CFcUPJqyvOMNK9BnLN5=BxT7daakyFHfr9TxLFU2kWa0x7g@mail.gmail.com>

Perhaps I has something like this earlier.
So wait and try again.

On Mon, Jan 27, 2014 at 9:52 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> Hello,
>
> I'm having difficulty with replying to a message in rietveld.
>
> Here's a screenshot of the exception: http://goo.gl/70iQ5v
> (AttributeError at /review/20356/publish)
>
> Is this a known issue? Maybe I'm doing something wrong?
>
> Yury
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers



-- 
Thanks,
Andrew Svetlov

From yselivanov.ml at gmail.com  Mon Jan 27 21:10:27 2014
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Mon, 27 Jan 2014 15:10:27 -0500
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <1390852571.2289.1.camel@fsol>
References: <52E6B8F0.9050908@gmail.com> <1390852571.2289.1.camel@fsol>
Message-ID: <52E6BD33.3050803@gmail.com>

I've tried multiple times, yes.

Yury

On 1/27/2014, 2:56 PM, Antoine Pitrou wrote:
> On lun., 2014-01-27 at 14:52 -0500, Yury Selivanov wrote:
>> Hello,
>>
>> I'm having difficulty with replying to a message in rietveld.
>>
>> Here's a screenshot of the exception: http://goo.gl/70iQ5v
>> (AttributeError at /review/20356/publish)
>>
>> Is this a known issue? Maybe I'm doing something wrong?
> Have you tried more than once? I've experienced sporadic errors at
> times.
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers


From rdmurray at bitdance.com  Mon Jan 27 21:13:18 2014
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 27 Jan 2014 15:13:18 -0500
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <52E6B8F0.9050908@gmail.com>
References: <52E6B8F0.9050908@gmail.com>
Message-ID: <20140127201319.7509C2500CE@webabinitio.net>

On Mon, 27 Jan 2014 14:52:16 -0500, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> Hello,
> 
> I'm having difficulty with replying to a message in rietveld.
> 
> Here's a screenshot of the exception: http://goo.gl/70iQ5v
> (AttributeError at /review/20356/publish)
> 
> Is this a known issue? Maybe I'm doing something wrong?

There have been occasional problems with the email interface in our
rietveld instance.  I'm not sure if your traceback matches the other
problems, and I don't remember if those problems were actually solved.
If you restart your session (starting from the bug tracker) does the
problem reproduce?

--David

From yselivanov.ml at gmail.com  Mon Jan 27 21:18:34 2014
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Mon, 27 Jan 2014 15:18:34 -0500
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <20140127201319.7509C2500CE@webabinitio.net>
References: <52E6B8F0.9050908@gmail.com>
 <20140127201319.7509C2500CE@webabinitio.net>
Message-ID: <52E6BF1A.30103@gmail.com>

OK, I've tried another browser (regularly I use Safari, this
time I was trying it with Chrome) -- same thing.

For those who want to try to reproduce it:

1. Open http://bugs.python.org/issue20356
2. Click 'review' for pos_only_format_02.patch
3. Click on message from @larry
4. Hit 'reply' link for it
5. Erase everything from the text area and type something in
5. Submit the form.

Yury

On 1/27/2014, 3:13 PM, R. David Murray wrote:
> On Mon, 27 Jan 2014 14:52:16 -0500, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>> Hello,
>>
>> I'm having difficulty with replying to a message in rietveld.
>>
>> Here's a screenshot of the exception: http://goo.gl/70iQ5v
>> (AttributeError at /review/20356/publish)
>>
>> Is this a known issue? Maybe I'm doing something wrong?
> There have been occasional problems with the email interface in our
> rietveld instance.  I'm not sure if your traceback matches the other
> problems, and I don't remember if those problems were actually solved.
> If you restart your session (starting from the bug tracker) does the
> problem reproduce?
>
> --David
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers


From solipsis at pitrou.net  Mon Jan 27 21:24:33 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 27 Jan 2014 21:24:33 +0100
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <52E6BF1A.30103@gmail.com>
References: <52E6B8F0.9050908@gmail.com>
 <20140127201319.7509C2500CE@webabinitio.net> <52E6BF1A.30103@gmail.com>
Message-ID: <1390854273.2289.2.camel@fsol>

On lun., 2014-01-27 at 15:18 -0500, Yury Selivanov wrote:
> OK, I've tried another browser (regularly I use Safari, this
> time I was trying it with Chrome) -- same thing.
> 
> For those who want to try to reproduce it:
> 
> 1. Open http://bugs.python.org/issue20356
> 2. Click 'review' for pos_only_format_02.patch
> 3. Click on message from @larry
> 4. Hit 'reply' link for it
> 5. Erase everything from the text area and type something in
> 5. Submit the form.

Well, it worked here (Firefox).
As a sidenote, why is Larry green on this page?

Regards

Antoine.



From yselivanov.ml at gmail.com  Mon Jan 27 21:31:37 2014
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Mon, 27 Jan 2014 15:31:37 -0500
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <1390854273.2289.2.camel@fsol>
References: <52E6B8F0.9050908@gmail.com>
 <20140127201319.7509C2500CE@webabinitio.net> <52E6BF1A.30103@gmail.com>
 <1390854273.2289.2.camel@fsol>
Message-ID: <52E6C229.3090202@gmail.com>

On more note:

I'm using open-id (google) to sign in on bugs.python.org

Yury

On 1/27/2014, 3:24 PM, Antoine Pitrou wrote:
> On lun., 2014-01-27 at 15:18 -0500, Yury Selivanov wrote:
>> OK, I've tried another browser (regularly I use Safari, this
>> time I was trying it with Chrome) -- same thing.
>>
>> For those who want to try to reproduce it:
>>
>> 1. Open http://bugs.python.org/issue20356
>> 2. Click 'review' for pos_only_format_02.patch
>> 3. Click on message from @larry
>> 4. Hit 'reply' link for it
>> 5. Erase everything from the text area and type something in
>> 5. Submit the form.
> Well, it worked here (Firefox).
> As a sidenote, why is Larry green on this page?
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers


From martin at v.loewis.de  Mon Jan 27 22:45:27 2014
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 27 Jan 2014 22:45:27 +0100
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <1390854273.2289.2.camel@fsol>
References: <52E6B8F0.9050908@gmail.com>
 <20140127201319.7509C2500CE@webabinitio.net> <52E6BF1A.30103@gmail.com>
 <1390854273.2289.2.camel@fsol>
Message-ID: <52E6D377.5030102@v.loewis.de>

Am 27.01.14 21:24, schrieb Antoine Pitrou:

> As a sidenote, why is Larry green on this page?

Because he used the keyword LGTM.

Regards,
Martin



From solipsis at pitrou.net  Mon Jan 27 22:50:59 2014
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 27 Jan 2014 22:50:59 +0100
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <52E6D377.5030102@v.loewis.de>
References: <52E6B8F0.9050908@gmail.com>
 <20140127201319.7509C2500CE@webabinitio.net> <52E6BF1A.30103@gmail.com>
 <1390854273.2289.2.camel@fsol> <52E6D377.5030102@v.loewis.de>
Message-ID: <1390859459.2289.5.camel@fsol>

On lun., 2014-01-27 at 22:45 +0100, "Martin v. L?wis" wrote:
> Am 27.01.14 21:24, schrieb Antoine Pitrou:
> 
> > As a sidenote, why is Larry green on this page?
> 
> Because he used the keyword LGTM.

Ah, Looks Green To Me. Got it :-)

Regards

Antoine.



From martin at v.loewis.de  Mon Jan 27 23:01:17 2014
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 27 Jan 2014 23:01:17 +0100
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <52E6BF1A.30103@gmail.com>
References: <52E6B8F0.9050908@gmail.com>
 <20140127201319.7509C2500CE@webabinitio.net> <52E6BF1A.30103@gmail.com>
Message-ID: <52E6D72D.1080200@v.loewis.de>

Am 27.01.14 21:18, schrieb Yury Selivanov:
> OK, I've tried another browser (regularly I use Safari, this
> time I was trying it with Chrome) -- same thing.
> 
> For those who want to try to reproduce it:
> 
> 1. Open http://bugs.python.org/issue20356
> 2. Click 'review' for pos_only_format_02.patch
> 3. Click on message from @larry
> 4. Hit 'reply' link for it
> 5. Erase everything from the text area and type something in
> 5. Submit the form.

I can add a message just fine, but I think something is broken still.

Can you get your web browser to see the source of the reply form? I get

    <form method="POST" action="/review/20356/publish"
          id="message-reply-form">
      <input type="hidden" name="xsrf_token"
value="7e667aa15c51043fea022aa837edaaa5">
      <div></div>
      <input type="hidden" name="in_reply_to" value="" />
      <input type="hidden" name="subject" value="fix formatting of
positional-only parameters in inspect.Signature" />
      <input type="hidden" name="message_only" value="1" />
      <input type="submit" value="Send Message" />
      <input type="button" value="Discard" name="discard" />
      <input type="checkbox" name="send_mail" value="1"
             id="message-reply-send-mail" checked="checked" />
      <label>Send mail to reviewers</label>
    </form>

I believe the issue is the hidden in_reply_to field.

a) it shouldn't be an empty string (I think); if it wasn't, Rietveld
   might actually make insert it in a threaded way. IIUC, js ought
   to have inserted a value for in_reply_to.
b) if it is empty, it apparently crashes for you because it then finds
   that there is no message with the id "".

Looking a bit further - maybe Safari doesn't tell me the dynamic code.
I also see

<a href="javascript:M_replyToMessage('0', '2014/01/25 11:25:44',
'larry', 'Message_2687')"
                 id="message-reply-href-0">Reply</a>

which really ought to fill out the in_reply_to field (with Message_2687)

If anybody wants to investigate: the source of this is at

http://hg.python.org/tracker/rietveld

Regards,
Martin




From larry at hastings.org  Mon Jan 27 23:11:40 2014
From: larry at hastings.org (Larry Hastings)
Date: Mon, 27 Jan 2014 14:11:40 -0800
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <1390854273.2289.2.camel@fsol>
References: <52E6B8F0.9050908@gmail.com>
 <20140127201319.7509C2500CE@webabinitio.net> <52E6BF1A.30103@gmail.com>
 <1390854273.2289.2.camel@fsol>
Message-ID: <52E6D99C.1070406@hastings.org>


On 01/27/2014 12:24 PM, Antoine Pitrou wrote:
> As a sidenote, why is Larry green on this page?

Motion sickness.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140127/fce0e064/attachment.html>

From yselivanov.ml at gmail.com  Mon Jan 27 23:37:57 2014
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Mon, 27 Jan 2014 17:37:57 -0500
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <52E6D72D.1080200@v.loewis.de>
References: <52E6B8F0.9050908@gmail.com>
 <20140127201319.7509C2500CE@webabinitio.net> <52E6BF1A.30103@gmail.com>
 <52E6D72D.1080200@v.loewis.de>
Message-ID: <52E6DFC5.3040005@gmail.com>

Martin,

On 1/27/2014, 5:01 PM, "Martin v. L?wis" wrote:
> Am 27.01.14 21:18, schrieb Yury Selivanov:
>> OK, I've tried another browser (regularly I use Safari, this
>> time I was trying it with Chrome) -- same thing.
>>
>> For those who want to try to reproduce it:
>>
>> 1. Open http://bugs.python.org/issue20356
>> 2. Click 'review' for pos_only_format_02.patch
>> 3. Click on message from @larry
>> 4. Hit 'reply' link for it
>> 5. Erase everything from the text area and type something in
>> 5. Submit the form.
> I can add a message just fine, but I think something is broken still.
>
> Can you get your web browser to see the source of the reply form? I get
>
>      <form method="POST" action="/review/20356/publish"
>            id="message-reply-form">
>        <input type="hidden" name="xsrf_token"
> value="7e667aa15c51043fea022aa837edaaa5">
>        <div></div>
>        <input type="hidden" name="in_reply_to" value="" />
>        <input type="hidden" name="subject" value="fix formatting of
> positional-only parameters in inspect.Signature" />
>        <input type="hidden" name="message_only" value="1" />
>        <input type="submit" value="Send Message" />
>        <input type="button" value="Discard" name="discard" />
>        <input type="checkbox" name="send_mail" value="1"
>               id="message-reply-send-mail" checked="checked" />
>        <label>Send mail to reviewers</label>
>      </form>
>
> I believe the issue is the hidden in_reply_to field.
>
> a) it shouldn't be an empty string (I think); if it wasn't, Rietveld
>     might actually make insert it in a threaded way. IIUC, js ought
>     to have inserted a value for in_reply_to.
> b) if it is empty, it apparently crashes for you because it then finds
>     that there is no message with the id "".
>
> Looking a bit further - maybe Safari doesn't tell me the dynamic code.
> I also see
>
> <a href="javascript:M_replyToMessage('0', '2014/01/25 11:25:44',
> 'larry', 'Message_2687')"
>                   id="message-reply-href-0">Reply</a>
>
> which really ought to fill out the in_reply_to field (with Message_2687)

Sure, here is the form markup:


<form method="POST" action="/review/20356/publish" 
id="message-reply-form"><textarea rows="7" cols="70" name="message" 
style=""></textarea>
       <input type="hidden" name="xsrf_token" 
value="769e2ad622940b39cde28df56f486977">
       <div></div>
       <input type="hidden" name="in_reply_to" value="Message_2687">
       <input type="hidden" name="subject" value="fix formatting of 
positional-only parameters in inspect.Signature">
       <input type="hidden" name="message_only" value="1">
       <input type="submit" value="Send Message">
       <input type="button" value="Discard" name="discard">
       <input type="checkbox" name="send_mail" value="1" 
id="message-reply-send-mail-0" checked="checked">
       <label for="message-reply-send-mail-0">Send mail to reviewers</label>
     </form>

And here is what browser (Chrome, again) actually had sent to the server:

 1.
    message:
    Test
 2.
    xsrf_token:
    769e2ad622940b39cde28df56f486977
 3.
    in_reply_to:
    Message_2687
 4.
    subject:
    fix formatting of positional-only parameters in inspect.Signature
 5.
    message_only:
    1
 6.
    send_mail:
    1


So, the JS code is clearly working.

Yury

From martin at v.loewis.de  Tue Jan 28 08:07:53 2014
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 28 Jan 2014 08:07:53 +0100
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <52E6DFC5.3040005@gmail.com>
References: <52E6B8F0.9050908@gmail.com>
 <20140127201319.7509C2500CE@webabinitio.net> <52E6BF1A.30103@gmail.com>
 <52E6D72D.1080200@v.loewis.de> <52E6DFC5.3040005@gmail.com>
Message-ID: <52E75749.8090908@v.loewis.de>

Am 27.01.14 23:37, schrieb Yury Selivanov:
> So, the JS code is clearly working.

Unfortunately, I have no idea what the root problem might be.
a) I cannot reproduce it. Following your steps, I manage to post a
   reply every time.
b) It really ought to work. The specific error suggests that the message
   lookup failed. However, the message in question is certainly there,
   and it does work for other people.

Feel free to submit a bug report to the metatracker, but chances are low
that it gets fixed (unless by accident, e.g. when upgrading to a new
Rietveld code base fixes the problem).

Regards,
Martin



From andrew.svetlov at gmail.com  Wed Jan 29 17:55:04 2014
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Wed, 29 Jan 2014 18:55:04 +0200
Subject: [python-committers] [RELEASED] Python 3.3.4 release candidate 1
In-Reply-To: <52E60C8E.1050908@python.org>
References: <52E60C8E.1050908@python.org>
Message-ID: <CAL3CFcV4ALwveAN4jKkWDOxo2eU3ZQCOO9UG4GC9RV02Z9FXzg@mail.gmail.com>

Would you to accept fixes for http://bugs.python.org/issue20434 and
http://bugs.python.org/issue20437 before 3.3.4 final?

On Mon, Jan 27, 2014 at 9:36 AM, Georg Brandl <georg at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On behalf of the Python development team, I'm reasonably happy to announce the
> Python 3.3.4 release candidate 1.
>
> Python 3.3.4 includes several security fixes and over 120 bug fixes compared to
> the Python 3.3.3 release.
>
> This release fully supports OS X 10.9 Mavericks.  In particular, this release
> fixes an issue that could cause previous versions of Python to crash when typing
> in interactive mode on OS X 10.9.
>
> Python 3.3 includes a range of improvements of the 3.x series, as well as easier
> porting between 2.x and 3.x.  In total, almost 500 API items are new or improved
> in Python 3.3.  For a more extensive list of changes in the 3.3 series, see
>
>     http://docs.python.org/3.3/whatsnew/3.3.html
>
> and for the detailed changelog of 3.3.4, see
>
>     http://docs.python.org/3.3/whatsnew/changelog.html
>
> To download Python 3.3.4 rc1 visit:
>
>     http://www.python.org/download/releases/3.3.4/
>
> This is a preview release, please report any bugs to
>
>      http://bugs.python.org/
>
> The final version is scheduled to be released in two weeks' time, on or about
> the 10th of February.
>
> Enjoy!
>
> - --
> Georg Brandl, Release Manager
> georg at python.org
> (on behalf of the entire python-dev team and 3.3's contributors)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iEYEARECAAYFAlLmDI4ACgkQN9GcIYhpnLAr6wCePRbHF80k5goV4RUDBA5FfkwF
> rLUAnRg0RpL/b6apv+Dt2/sgnUd3hTPA
> =Z4Ss
> -----END PGP SIGNATURE-----
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers



-- 
Thanks,
Andrew Svetlov

From storchaka at gmail.com  Wed Jan 29 20:12:18 2014
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 29 Jan 2014 21:12:18 +0200
Subject: [python-committers] [RELEASED] Python 3.3.4 release candidate 1
In-Reply-To: <CAL3CFcV4ALwveAN4jKkWDOxo2eU3ZQCOO9UG4GC9RV02Z9FXzg@mail.gmail.com>
References: <52E60C8E.1050908@python.org>
 <CAL3CFcV4ALwveAN4jKkWDOxo2eU3ZQCOO9UG4GC9RV02Z9FXzg@mail.gmail.com>
Message-ID: <lcbjpi$436$2@ger.gmane.org>

29.01.14 18:55, Andrew Svetlov ???????(??):
> Would you to accept fixes for http://bugs.python.org/issue20434 and
> http://bugs.python.org/issue20437 before 3.3.4 final?

And http://bugs.python.org/issue20440.



From yselivanov.ml at gmail.com  Thu Jan 30 00:02:35 2014
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Wed, 29 Jan 2014 18:02:35 -0500
Subject: [python-committers] Code review tool (rietveld) bug
In-Reply-To: <52E75749.8090908@v.loewis.de>
References: <52E6B8F0.9050908@gmail.com>
 <20140127201319.7509C2500CE@webabinitio.net> <52E6BF1A.30103@gmail.com>
 <52E6D72D.1080200@v.loewis.de> <52E6DFC5.3040005@gmail.com>
 <52E75749.8090908@v.loewis.de>
Message-ID: <52E9888B.5090907@gmail.com>


On 1/28/2014, 2:07 AM, "Martin v. L?wis" wrote:
> Am 27.01.14 23:37, schrieb Yury Selivanov:
>> So, the JS code is clearly working.
> Unfortunately, I have no idea what the root problem might be.
> a) I cannot reproduce it. Following your steps, I manage to post a
>     reply every time.
> b) It really ought to work. The specific error suggests that the message
>     lookup failed. However, the message in question is certainly there,
>     and it does work for other people.
>
> Feel free to submit a bug report to the metatracker, but chances are low
> that it gets fixed (unless by accident, e.g. when upgrading to a new
> Rietveld code base fixes the problem).
>
Martin,

Thank you for looking into this. I guess I'll try to
debug this myself too, maybe on the weekend.

Yury