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

Re: What platforms should we remove support from?

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
November 10, 2018 23:09
Subject:
Re: What platforms should we remove support from?
Message ID:
CA+vYcVxQa1=X7jwre5rRry9H8a2NSVRfAV36LpeDBjtCOHtf9w@mail.gmail.com
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.

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