On Thu, Aug 14, 2008, M.-A. Lemburg wrote:
> On 2008-08-14 08:43, Martin v. L?wis wrote:
>>>For example, let's project dates for closing 2.6 and 3.0 now, and add
>>>them to PEP 361.
>>
>>My view is that they should be closed when 2.7 and 3.1 are released.
>
> Since we don't have a fixed release cy
On 2008-08-14 08:43, Martin v. Löwis wrote:
For example, let's project dates for closing 2.6 and 3.0 now, and add
them to PEP 361.
My view is that they should be closed when 2.7 and 3.1 are released.
Since we don't have a fixed release cycle, making the 2.(n-1)
maintenance time frame depend o
> For example, let's project dates for closing 2.6 and 3.0 now, and add
> them to PEP 361.
My view is that they should be closed when 2.7 and 3.1 are released.
Following another informal policy, we were going for an 18 months
release cycle at some time (2.6 clearly took longer), which would
mean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 13, 2008, at 7:11 PM, Martin v. Löwis wrote:
There's a difference between never being released, and unavailable in
the source repository.
So would you have preferred if I had forked another branch that still
contained these patches? Such br
On Wed, Aug 13, 2008 at 4:11 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> There's a difference between never being released, and unavailable in
>> the source repository.
>
> So would you have preferred if I had forked another branch that still
> contained these patches? Such branch can still
> There's a difference between never being released, and unavailable in
> the source repository.
So would you have preferred if I had forked another branch that still
contained these patches? Such branch can still be added now. Nothing
that gets added to the source repository ever becomes unavaila
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 13, 2008, at 10:29 AM, [EMAIL PROTECTED] wrote:
Why not migrate support for older releases to interested parties
outside of
the regular developer team? Presuming there is someone out there
with the
interest in maintaining, say, Python 2.2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 13, 2008, at 1:53 AM, Martin v. Löwis wrote:
Because there won't typically be sufficient testing and release
infrastructure to allow arbitrary bug fixes to be committed on the
branch. The buildbots are turned off, and nobody tests the release
> What I was trying to say is that you only see a single source download,
> which someone then takes, compiles and possibly redistributed or
> integrates into a product. As a result a single download can
> easily map to quite a few installations - and that's what we should
> base our assumptions on
On 2008-08-13 22:32, Martin v. Löwis wrote:
It's difficult to use such download numbers as hint for the number
of deployed installations. 2.4.5 was not released as binary, so
interested parties had to compile that version by themselves and
those installations don't show up in your statistics.
Y
> It's difficult to use such download numbers as hint for the number
> of deployed installations. 2.4.5 was not released as binary, so
> interested parties had to compile that version by themselves and
> those installations don't show up in your statistics.
You mean, they installed it *without* do
Why not migrate support for older releases to interested parties outside of
the regular developer team? Presuming there is someone out there with the
interest in maintaining, say, Python 2.2, they could take over the entire
responsibility for making releases, continuing to use the Subversion
repos
On 2008-08-13 15:20, Steve Holden wrote:
M.-A. Lemburg wrote:
Perhaps we should just document the maintenance of Python releases
more clearly and also plan for a final bug fix release 3 years after
the initial branch release. That way developers and users can also
adjust their plans accordingly.
M.-A. Lemburg wrote:
On 2008-08-13 07:53, Martin v. Löwis wrote:
Because there won't typically be sufficient testing and release
infrastructure to allow arbitrary bug fixes to be committed on the
branch. The buildbots are turned off, and nobody tests the release
candidate, no Windows binaries ar
On 2008-08-13 04:57, Guido van Rossum wrote:
And there's a reason for this slow uptake of Python 2.5: as more
and more servers run 64-bit OSes, the Py_ssize_t changes cause
serious trouble with Python C extensions that were not updated
by their authors.
I'm not sure what that has to do with any
On 2008-08-13 07:53, Martin v. Löwis wrote:
Because there won't typically be sufficient testing and release
infrastructure to allow arbitrary bug fixes to be committed on the
branch. The buildbots are turned off, and nobody tests the release
candidate, no Windows binaries are provided - thus, cha
>> Because there won't typically be sufficient testing and release
>> infrastructure to allow arbitrary bug fixes to be committed on the
>> branch. The buildbots are turned off, and nobody tests the release
>> candidate, no Windows binaries are provided - thus, chances are very
>> high that a bug f
17 matches
Mail list logo