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 op
On 6 December 2010 18:55, "Martin v. Löwis" wrote:
> Am 06.12.2010 14:40, schrieb Floris Bruynooghe:
>> On 6 December 2010 09:18, "Martin v. Löwis" wrote:
Also, it is not clear what to do about distributions/OSs
without any official EOL or life cycles.
>>>
>>> Here my proposal stands: 1
>> 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
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.
>
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
Hi,
2010/12/6 "Martin v. Löwis"
> 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 have to step for
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. Howeve
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 it
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 poli
Am 06.12.2010 14:40, schrieb Floris Bruynooghe:
> On 6 December 2010 09:18, "Martin v. Löwis" 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)? Tha
On 6 December 2010 09:18, "Martin v. Löwis" 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.
(Personally
"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.
Nick Coghlan 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.
___
Python-Dev mai
> 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
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 [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 BSD platforms of what
is currently in use, EOL and the future.
On Mon, Dec 6, 2010 at 5:28 PM, "Martin v. Löwis" wrote:
> Am 06.12.2010 05:36, schrieb Nick Coghlan:
>> On Mon, Dec 6, 2010 at 7:48 AM, "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
>>
Nick Coghlan gmail.com> writes:
> On Mon, Dec 6, 2010 at 7:48 AM, "Martin v. Löwis" 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 the
> ven
Am 06.12.2010 05:36, schrieb Nick Coghlan:
> On Mon, Dec 6, 2010 at 7:48 AM, "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 s
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
Python-D
On Mon, Dec 6, 2010 at 7:48 AM, "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 i
> 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, a
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.
>
> 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. T
On Sun, Dec 5, 2010 at 14:14, Antoine Pitrou wrote:
> On Sun, 05 Dec 2010 22:48:49 +0100
> "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 whe
On Sun, 05 Dec 2010 22:48:49 +0100
"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 liste
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 th
27 matches
Mail list logo
