develooper Front page | perl.perl5.porters | Postings from November 2018

Re: What platforms should we remove support from?

Thread Previous | Thread Next
From:
Sawyer X
Date:
November 11, 2018 08:56
Subject:
Re: What platforms should we remove support from?
Message ID:
7b4bee3d-1e15-cf18-40d0-f0b0f26f63c1@gmail.com

On 11/11/18 1:09 AM, Craig A. Berry wrote:
> On Sat, Nov 10, 2018 at 12:33 PM Sawyer X <xsawyerx@gmail.com> wrote:
>>
>> On 11/10/18 3:29 PM, Tomasz Konojacki wrote:
>>> On Sat, 10 Nov 2018 07:08:32 -0600
>>> "Craig A. Berry" <craig.a.berry@gmail.com> wrote:
>>>
>>>> I believe Tru64 (formerly known as DEC OSF/1 or Digital UNIX)
>>>> officially was EOLed by HPE in 2012, but there are systems still in
>>>> use
>>> I don't think that really matters. If someone is fine with running
>>> unsupported version of an operating system, they should be fine with
>>> running older perl version. It's not like Perl 5.28 will suddenly stop
>>> working for them if we drop OSF support in 5.30.
>>>
>>> 5.28 will be considered "modern enough" for roughly a decade. For
>>> example the *latest* version of RHEL/CentOS ships with 5.16.3. I think
>>> it's the most popular server linux distribution, which means that 5.16.3
>>> is one of the most popular perl versions today. 5.28 is *much* newer
>>> than 5.16.
>>>
>>> The above is also the reason why I think there's no need for deprecation
>>> periods when we're dropping support for a platform.
>>
>> I don't see a need for deprecation periods when dropping platform
>> support either. However, Craig raises a different point.
>>
>>
>> If it takes little to support it, and there is a reason to believe
>> someone *is* using it without letting us know, why drop it?
>>>> and there aren't really *that* many occurrences of __osf__ in the
>>>> C code or dec_osf in Perl code, so it doesn't strike me as that
>>>> intrusive a port.
>>> If there's more than zero #ifdefs in code, that's a good enough reason
>>> to get rid of it for me. Especially considering the fact that most of us
>>> don't have access to this platform and we have no way of knowing if our
>>> changes break anything on it.
>>
>> I don't fully buy that. Development is not always a pretty process, and
>> support is even further from that ideal. Not being able to test this
>> platform is a consideration, but that alone should only be a deciding
>> factor if there is no reason to assume there are no users.
>>
>>
>> So I'll repeat Craig's question, because it seems to be valuable here:
>>
>>
>> What is the current cost of maintaining this support?
> Answering my own question, zero for all practical purposes.  Most of
> the Tru64-specific stuff has been there for decades and I've never
> heard anyone complain about it.  Also, FWIW, the most recent commit I
> could find that explicitly mentions Tru64 was 16 months ago:
>
> <https://perl5.git.perl.org/perl.git/commitdiff/a5d565cd966ec58e5f3ca05b219fe919086f43b1>
>
> and it simplifies the code in a platform-neutral way.   In the history
> of Perl, active signs of maintenance within the last two years counts
> as pretty active maintenance and is worth a heck of a lot more than
> vendor support.  And people who are able to abstract out how to
> satisfy a picky compiler in a way that works for every compiler are
> not that easy to come by, so why chase them off?
>
> I can find exactly two references to __osf__ in the .c files that do
> not come from auto-generated code, both in perlio.c, and one of which
> does the exact same thing that separate branches of the #ifdef jungle
> do for OpenBSD, FreeBSD, and Cygwin.  Perhaps some of that could be
> simplified or done in a better way, but I think this conversation has
> already taken way more time than it's ever taken anyone to work around
> those two lines of code.


Let's keep it supported then.


Thanks, Craig.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About