On 6 December 2010 18:55, Martin v. Löwis mar...@v.loewis.de wrote:
Am 06.12.2010 14:40, schrieb Floris Bruynooghe:
On 6 December 2010 09:18, Martin v. Löwis mar...@v.loewis.de wrote:
Also, it is not clear what to do about distributions/OSs
without any official EOL or life cycles.
Here my
On Tue, 2010-12-07 at 00:05 +0100, Martin v. Löwis wrote:
So by this policy, RHEL and SuSE users would be off worse than with
my original proposal (10 years).
Red Hat continues to provide patches for RHEL within the Extended Life
Cycle (years 8, 9 and 10), but it's an optional add-on.
Am 06.12.2010 09:36, schrieb Jeroen Ruigrok van der Werven:
-On [20101206 08:30], Martin v. Löwis (mar...@v.loewis.de) wrote:
As a counter-example, I think the only way to phase out support
for old OpenBSD releases is that we set a date.
If you want, I can provide you with specifics on the
EOL dates of prominent Linux distribution :
I think I would need more information than that. Nick's proposal was
more specific: when does the vendor stop producing patches? This is
a clear criterion, and one that I support.
RHEL:
https://access.redhat.com/support/policy/updates/errata/
My
Nick Coghlan ncoghlan at gmail.com writes:
I would be fine with an EOL based policy for single-vendor platforms
(specifically Solaris and Windows) and a date-based policy for
everything else.
+1
I also think this would be for the best.
___
Martin v. Löwis wrote:
[...]
Ubuntu:
http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Version_timeline
(http://www.ubuntu.com/products/ubuntu/release-cycle seems to be down)
I'd prefer something more official than Wikipedia, though.
https://wiki.ubuntu.com/Releases
-Andrew.
On 6 December 2010 09:18, Martin v. Löwis mar...@v.loewis.de wrote:
Also, it is not clear what to do about distributions/OSs
without any official EOL or life cycles.
Here my proposal stands: 10 years, by default.
How about max(EOL, 10years)? That sounds like it could be a useful guideline.
Am 06.12.2010 14:40, schrieb Floris Bruynooghe:
On 6 December 2010 09:18, Martin v. Löwis mar...@v.loewis.de wrote:
Also, it is not clear what to do about distributions/OSs
without any official EOL or life cycles.
Here my proposal stands: 10 years, by default.
How about max(EOL, 10years)?
On 12/6/2010 4:08 AM, Martin v. Löwis wrote:
For Windows and Solaris, it seems that some users continue to use the
system after the vendor stops producing patches, and dislike the
prospect of not having Python releases for it anymore. However, they
are in clear minority, so by our current
On 12/6/10 10:55 AM, Martin v. Löwis wrote:
Of course, with these old systems, I really wonder: why do they need
current Python releases? 2.7 will remain available and maintained for
some time, and 3.1 will at least see security fixes for some more time -
something that the base system itself
Am 06.12.2010 20:25, schrieb Terry Reedy:
On 12/6/2010 4:08 AM, Martin v. Löwis wrote:
For Windows and Solaris, it seems that some users continue to use the
system after the vendor stops producing patches, and dislike the
prospect of not having Python releases for it anymore. However, they
Hi,
2010/12/6 Martin v. Löwis mar...@v.loewis.de
In my original posting, I proposed a clause where support could be
extended as long as an individual steps forward to provide that support.
So if XP remains popular by the time Microsoft stops providing patches
for it, some volunteer would
On 12/6/2010 3:46 PM, Martin v. Löwis wrote:
Am 06.12.2010 20:25, schrieb Terry Reedy:
I quite suspect that XP will be in major use (more than say, current
BSD) for some years after MS stops official support. Why rush to drop
it?
What rush to drop it,
On the day MS stops support. But it
On Mon, 2010-12-06 at 10:18 +0100, Martin v. Löwis wrote:
EOL dates of prominent Linux distribution :
I think I would need more information than that. Nick's proposal was
more specific: when does the vendor stop producing patches? This is
a clear criterion, and one that I support.
RHEL:
So by this policy, RHEL and SuSE users would be off worse than with
my original proposal (10 years).
Red Hat continues to provide patches for RHEL within the Extended Life
Cycle (years 8, 9 and 10), but it's an optional add-on.
My understanding is that you keep the patches available - but
I'd like to tighten PEP 11, and declare a policy that systems
older than ten years at the point of a feature release are not
supported anymore by default. Older systems where support is still
maintained need to be explicitly listed in the PEP, along with
the name of the responsible maintainer (I
On Sun, 05 Dec 2010 22:48:49 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
I'd like to tighten PEP 11, and declare a policy that systems
older than ten years at the point of a feature release are not
supported anymore by default. Older systems where support is still
maintained need to be
On Sun, Dec 5, 2010 at 14:14, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 05 Dec 2010 22:48:49 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
I'd like to tighten PEP 11, and declare a policy that systems
older than ten years at the point of a feature release are not
supported anymore
The other major system affected by this would be Windows 2000, for which
we already decided to not support it anymore.
Is there any 2000-specific code (as opposed to XP-compatible)?
Yes: a number of APIs didn't exist in W2k, so we currently use
LoadLibrary/GetProcAddress to call them. These
On 12/5/2010 4:48 PM, Martin v. Löwis wrote:
I'd like to tighten PEP 11, and declare a policy that systems
older than ten years at the point of a feature release are not
supported anymore by default. Older systems where support is still
maintained need to be explicitly listed in the PEP, along
The other major system affected by this would be Windows 2000, for which
we already decided to not support it anymore.
WinXP (released August 2001) should be supported a lot longer than another
year ;-) . It is still supported and installed on new systems.
Good catch. Windows XP, according
On Mon, Dec 6, 2010 at 7:48 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I'd like to tighten PEP 11, and declare a policy that systems
older than ten years at the point of a feature release are not
supported anymore by default. Older systems where support is still
maintained need to be
On 2010/12/06 6:48, Martin v. Löwis wrote:
The other major system affected by this would be Windows 2000, for which
we already decided to not support it anymore.
Opinions?
I'm +1/2 for supporting Windows 2000...
___
Python-Dev mailing list
Am 06.12.2010 05:36, schrieb Nick Coghlan:
On Mon, Dec 6, 2010 at 7:48 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I'd like to tighten PEP 11, and declare a policy that systems
older than ten years at the point of a feature release are not
supported anymore by default. Older systems where
Nick Coghlan ncoghlan at gmail.com writes:
On Mon, Dec 6, 2010 at 7:48 AM, Martin v. Löwis martin at v.loewis.de
wrote:
I'd like to tighten PEP 11
Opinions?
I would prefer to be guided by vendor EOL dates rather than our own
arbitrary 10 year limit. The EOL guide I would suggest is Is
On Mon, Dec 6, 2010 at 5:28 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 06.12.2010 05:36, schrieb Nick Coghlan:
On Mon, Dec 6, 2010 at 7:48 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I'd like to tighten PEP 11, and declare a policy that systems
older than ten years at the point of a
26 matches
Mail list logo
