On 20 January 2012 03:57, Brian Curtin br...@python.org wrote:
FWIW, it might well be that I can't be available for the 3.3 final
release (I haven't finalized my vacation schedule yet for August).
In the interest of not having Windows releases depend on one person,
and having gone through
On Fri, 20 Jan 2012 12:57:45 +
Paul Moore p.f.mo...@gmail.com wrote:
On 20 January 2012 03:57, Brian Curtin br...@python.org wrote:
FWIW, it might well be that I can't be available for the 3.3 final
release (I haven't finalized my vacation schedule yet for August).
In the interest of
Am 20.01.2012 00:54, schrieb Martin v. Löwis:
I can't help noticing that so far, worries about the workload came mostly
from
people who don't actually bear that load (this is no accusation!), while
those
that do are the proponents of the PEP...
Ok, so let me add then that I'm worried
On 20/01/2012 19:14, Georg Brandl wrote:
Am 20.01.2012 00:54, schrieb Martin v. Löwis:
I can't help noticing that so far, worries about the workload came mostly from
people who don't actually bear that load (this is no accusation!), while those
that do are the proponents of the PEP...
Ok, so
Am 20.01.2012 21:08, schrieb Tim Golden:
On 20/01/2012 19:14, Georg Brandl wrote:
Am 20.01.2012 00:54, schrieb Martin v. Löwis:
I can't help noticing that so far, worries about the workload came mostly
from
people who don't actually bear that load (this is no accusation!), while
those
On Thu, 19 Jan 2012 11:12:06 +1100
Steven D'Aprano st...@pearwood.info wrote:
Antoine Pitrou wrote:
Le jeudi 19 janvier 2012 à 00:25 +0900, Stephen J. Turnbull a écrit :
You claim people won't use stable releases because of not enough
alphas? That sounds completely unrelated.
On Thu, Jan 19, 2012 at 9:07 PM, Antoine Pitrou solip...@pitrou.net wrote:
I fear the day that people asking
questions on the tutor or python-list mailing lists will have to say (e.g.)
I'm using Python 3.4.1 and standard library 1.2.7 in order to specify the
version they're using.
Yeah,
Am 19.01.2012 01:12, schrieb Steven D'Aprano:
One on-going complaint is that Python-Dev doesn't have the manpower or time
to
do everything that needs to be done. Bugs languish for months or years
because
nobody has the time to look at it. Will going to a more rapid release cycle
give
I can't help noticing that so far, worries about the workload came mostly from
people who don't actually bear that load (this is no accusation!), while those
that do are the proponents of the PEP...
Ok, so let me add then that I'm worried about the additional work-load.
I'm particularly
On Fri, Jan 20, 2012 at 9:54 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I can't help noticing that so far, worries about the workload came mostly
from
people who don't actually bear that load (this is no accusation!), while
those
that do are the proponents of the PEP...
Ok, so let me
On Thu, Jan 19, 2012 at 17:54, Martin v. Löwis mar...@v.loewis.de wrote:
Ok, so let me add then that I'm worried about the additional work-load.
I'm particularly worried about the coordination of vacation across the
three people that work on a release. It might well not be possible to
make
On Wed, 18 Jan 2012 07:52:20 +
Paul Moore p.f.mo...@gmail.com wrote:
On 18 January 2012 07:46, Georg Brandl g.bra...@gmx.net wrote:
But I am dubious that releases that are obsolete in 6 months and lack
3rd party support will see much production use.
Whether people would use the
On Wed, 18 Jan 2012 11:37:08 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
availability of release management volunteers,
Dramatic increase here. It may look like RM is not so demanding --
run a few scripts to put out the alphas/betas/releases. But the RM
needs to stay on top of
This won't be a surprise to Antoine or Georg (since I've already
expressed the same opinion privately), but I'm -1 on the idea of
official releases of the whole shebang every 6 months. We're not
Ubuntu, Fedora, Chrome or Firefox with a for-profit company (or large
foundation) with multiple paid
Antoine Pitrou writes:
Since testing is the bottleneck on what users consider to be
available for me, you cannot decrease the amount of testing (alpha,
beta releases) by anywhere near the amount you're increasing
frequency, or you're just producing as is snapshots.
The point is
Le mercredi 18 janvier 2012 à 21:48 +0900, Stephen J. Turnbull a écrit :
My claim is that I don't expect much uptake if you
don't do close to as many of what are called alpha and beta tests
on python-dev as are currently done.
You claim people won't use stable releases because of not enough
Antoine Pitrou writes:
You claim people won't use stable releases because of not enough
alphas? That sounds completely unrelated.
Surely testing is related to user perceptions of stability. More
testing helps reduce bugs in released software, which improves user
perception of stability,
Le jeudi 19 janvier 2012 à 00:25 +0900, Stephen J. Turnbull a écrit :
You claim people won't use stable releases because of not enough
alphas? That sounds completely unrelated.
Surely testing is related to user perceptions of stability. More
testing helps reduce bugs in released
On Wed, Jan 18, 2012 at 09:26:19PM +1000, Nick Coghlan wrote:
My original suggestion to Antoine and Georg for 3.4 was that we simply
propose to Larry Hastings (the 3.4 RM) that we spread out the release
cycle, releasing the first alpha after ~6 months, the second after
about ~12, then rolling
On Tuesday, January 17, 2012, Antoine Pitrou solip...@pitrou.net wrote:
We would like to propose the following PEP to change (C)Python's release
cycle. Discussion is welcome, especially from people involved in the
release process, and maintainers from third-party distributions of
Python.
As a
Hello Dirkjan,
On Wed, 18 Jan 2012 18:32:22 +0100
Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Tuesday, January 17, 2012, Antoine Pitrou solip...@pitrou.net wrote:
We would like to propose the following PEP to change (C)Python's release
cycle. Discussion is welcome, especially from people
Am 18.01.2012 16:25, schrieb Stephen J. Turnbull:
Antoine Pitrou writes:
You claim people won't use stable releases because of not enough
alphas? That sounds completely unrelated.
Surely testing is related to user perceptions of stability. More
testing helps reduce bugs in released
Antoine Pitrou wrote:
Le jeudi 19 janvier 2012 à 00:25 +0900, Stephen J. Turnbull a écrit :
You claim people won't use stable releases because of not enough
alphas? That sounds completely unrelated.
Surely testing is related to user perceptions of stability. More
testing helps reduce
On Wed, Jan 18, 2012 at 6:55 PM, Georg Brandl g.bra...@gmx.net wrote:
The main reason is changes in the library. We have been getting complaints
about the standard library bitrotting for years now, and one of the main
reasons it's so hard to a) get decent code into the stdlib and b) keep it
Georg Brandl writes:
The status quo really isn't all that bad applies to any PEP. Also,
compared to most PEPs, it is quite easy to revert to the previous
state of things if they don't work out as wanted.
That depends on how doesn't work out plays out. If meeting the
schedule *and*
Steven D'Aprano writes:
Pardon me, but people like Stephen Turnbull are *users* of Python, exactly
the
sort of people you DO have to convince that moving to an accelerated or more
complex release process will result in a better product.
Well, to be fair, Antoine is right in excluding
Hello,
We would like to propose the following PEP to change (C)Python's release
cycle. Discussion is welcome, especially from people involved in the
release process, and maintainers from third-party distributions of
Python.
Regards
Antoine.
PEP: 407
Title: New release cycle and introducing
On Tue, Jan 17, 2012 at 1:34 PM, Antoine Pitrou solip...@pitrou.net wrote:
Under the proposed scheme, there would be two kinds of feature
versions (sometimes dubbed minor versions, for example 3.2 or 3.3):
normal feature versions and long-term support (LTS) versions.
...
A new feature version
If minor/feature releases are introducing breaking changes perhaps it's
time to adopt accelerated major versioning schedule. For instance there are
breaking ABI changes between 3.0/3.1, and 3.2, and while acceptable for the
early adoption state of Python 3, such changes should normally be reserved
Hello,
On Wed, 18 Jan 2012 10:04:19 +1100
Matt Joiner anacro...@gmail.com wrote:
If minor/feature releases are introducing breaking changes perhaps it's
time to adopt accelerated major versioning schedule.
The PEP doesn't propose to accelerate compatibility breakage. So I don't
think a change
On 1/17/2012 3:34 PM, Antoine Pitrou wrote:
Hello,
We would like to propose the following PEP to change (C)Python's release
cycle. Discussion is welcome, especially from people involved in the
release process, and maintainers from third-party distributions of
Python.
Regards
Antoine.
PEP:
On Tue, 17 Jan 2012 18:29:11 -0500
Terry Reedy tjre...@udel.edu wrote:
To me, as I understand the proposal, the title is wrong. Our current
feather releases already are long-term support versions. They get bugfix
releases at close to 6 month intervals for 1 1/2 -2 years and security
fixes
Hi,
On 17/01/2012 22.34, Antoine Pitrou wrote:
[...]
Proposal
Under the proposed scheme, there would be two kinds of feature
versions (sometimes dubbed minor versions, for example 3.2 or 3.3):
normal feature versions and long-term support (LTS) versions.
Normal feature versions
On Tue, Jan 17, 2012 at 3:50 PM, Ezio Melotti ezio.melo...@gmail.com wrote:
* What is the effect on PyPy/Jython/IronPython? Can they just skip the
feature releases and focus on the LTS ones?
At least for IronPython it's unlikely we'd be able track the feature
releases. We're still trying to
Executive summary:
My take is show us the additional resources, and don't be stingy!
Sorry, Antoine, I agree with your goals, but I think you are too
optimistic about the positive effects and way too optimistic about the
costs.
Antoine Pitrou writes:
Finding a release cycle for an open-source
On 1/17/2012 6:42 PM, Antoine Pitrou wrote:
On Tue, 17 Jan 2012 18:29:11 -0500
Terry Reedytjre...@udel.edu wrote:
To me, as I understand the proposal, the title is wrong. Our current
feather releases already are long-term support versions. They get bugfix
releases at close to 6 month
Am 18.01.2012 05:32, schrieb Terry Reedy:
On 1/17/2012 6:42 PM, Antoine Pitrou wrote:
On Tue, 17 Jan 2012 18:29:11 -0500
Terry Reedytjre...@udel.edu wrote:
To me, as I understand the proposal, the title is wrong. Our current
feather releases already are long-term support versions. They get
On 18 January 2012 04:32, Terry Reedy tjre...@udel.edu wrote:
It's really about making feature releases more frequent,
not making previews available during development.
Given the difficulty of making a complete windows build, it would be nice to
have one made available every 6 months,
Am 18.01.2012 01:24, schrieb Jeff Hardy:
On Tue, Jan 17, 2012 at 3:50 PM, Ezio Melotti ezio.melo...@gmail.com wrote:
* What is the effect on PyPy/Jython/IronPython? Can they just skip the
feature releases and focus on the LTS ones?
At least for IronPython it's unlikely we'd be able track
On 18 January 2012 07:46, Georg Brandl g.bra...@gmx.net wrote:
But I am dubious that releases that are obsolete in 6 months and lack
3rd party support will see much production use.
Whether people would use the releases is probably something that only
they can tell us -- that's why a community
Am 18.01.2012 00:50, schrieb Ezio Melotti:
Hi,
On 17/01/2012 22.34, Antoine Pitrou wrote:
[...]
Proposal
Under the proposed scheme, there would be two kinds of feature
versions (sometimes dubbed minor versions, for example 3.2 or 3.3):
normal feature versions and long-term
41 matches
Mail list logo
