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!), wh
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 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'
On Fri, 20 Jan 2012 12:57:45 +
Paul Moore wrote:
> On 20 January 2012 03:57, Brian Curtin 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 releas
On 20 January 2012 03:57, Brian Curtin 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 building the
On Thu, Jan 19, 2012 at 17:54, "Martin v. Löwis" 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 any release fo
On Fri, Jan 20, 2012 at 9:54 AM, "Martin v. Löwis" 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 add th
> 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 wor
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
> g
On Thu, Jan 19, 2012 at 9:07 PM, Antoine Pitrou 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, that's my bi
On Thu, 19 Jan 2012 11:12:06 +1100
Steven D'Aprano 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.
> >>
> >> Surely t
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 excludi
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*
On Wed, Jan 18, 2012 at 6:55 PM, Georg Brandl 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
> maintained is
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 bu
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 r
Hello Dirkjan,
On Wed, 18 Jan 2012 18:32:22 +0100
Dirkjan Ochtman wrote:
> On Tuesday, January 17, 2012, Antoine Pitrou 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 proces
On Tuesday, January 17, 2012, Antoine Pitrou 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 Gentoo packager
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 rolli
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 relea
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, e
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 en
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.
>
> T
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 emp
On Wed, 18 Jan 2012 11:37:08 +0900
"Stephen J. Turnbull" 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 breaking news
On Wed, 18 Jan 2012 07:52:20 +
Paul Moore wrote:
> On 18 January 2012 07:46, Georg Brandl 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
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 versio
On 18 January 2012 07:46, Georg Brandl 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 survey is
Am 18.01.2012 01:24, schrieb Jeff Hardy:
> On Tue, Jan 17, 2012 at 3:50 PM, Ezio Melotti 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
> rele
On 18 January 2012 04:32, Terry Reedy 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, regardless of h
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 Reedy wrote:
>>>
>>> To me, as I understand the proposal, the title is wrong. Our current
>>> feather releases already are long-term support versions. They get bug
On 1/17/2012 6:42 PM, Antoine Pitrou wrote:
On Tue, 17 Jan 2012 18:29:11 -0500
Terry Reedy 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 ye
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-sour
On Tue, Jan 17, 2012 at 3:50 PM, Ezio Melotti 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 catch up as it is.
Hon
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 wou
On Tue, 17 Jan 2012 18:29:11 -0500
Terry Reedy 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 for 3 years
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: 4
Hello,
On Wed, 18 Jan 2012 10:04:19 +1100
Matt Joiner 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 in numbering is r
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
On Tue, Jan 17, 2012 at 1:34 PM, Antoine Pitrou 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 would be relea
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 lo
41 matches
Mail list logo
