From @nwc10

I mailed this to the list at the time, but it got Warnocked

I'd like at least someone else to consider an answer, so here it is as an RT
ticket. OK, technically someone can close it without commenting, but I don't
forsee that happening. :-)

I have pushed the commit to blead that deletes all the special case
code for VM/ESA, which should escape in a dev release tomorrow.

Unlike USA, VM/ESA had mentions in perlport.pod.
I have deleted them. I'm not *sure* if this was the right thing to do.
Specifically, I did this​:

@​@​ -1975,14 +1971,14 @​@​ syntax if it is intended to resolve to a valid path.

=item syscall

-Not implemented. (Win32, VMS, S<RISC OS>, VOS, VM/ESA)
+Not implemented. (Win32, VMS, S<RISC OS>, VOS)

=item sysopen

The traditional "0", "1", and "2" MODEs are implemented with different
numeric values on some systems. The flags exported by C<Fcntl>
(O_RDONLY, O_WRONLY, O_RDWR) should work everywhere though. (S<Mac
-OS>, OS/390, VM/ESA)
+OS>, OS/390)

=item system

Notice that an *other* platform that is mentioned as having non-standard
O_RDONLY etc is Mac OS. This isn't well phrased. It's Mac OS *classic*.
Likewise, the earlier text in there about \r line endings is *classic*,
not Darwin.

So

0) Should perlport represent the current state of Perl portability, or
  historical things too?

which probably then answers

1) Should we remove or correct the Mac OS references?

2) Should I have removed the VM/ESA references?

Nicholas Clark

From @xdg

On Wed, Sep 19, 2012 at 12​:48 PM, Nicholas Clark
<perlbug-followup@​perl.org> wrote​:

0) Should perlport represent the current state of Perl portability, or
historical things too?

I vote "current"

--
David Golden <xdg@​xdg.me>
Take back your inbox! → http​://www.bunchmail.com/
Twitter/IRC​: @​xdg

The RT System itself - Status changed from 'new' to 'open'

From @jkeenan

On Wed Sep 19 09​:48​:42 2012, nicholas wrote​:

Notice that an *other* platform that is mentioned as having non-standard
O_RDONLY etc is Mac OS. This isn't well phrased. It's Mac OS *classic*.
Likewise, the earlier text in there about \r line endings is *classic*,
not Darwin.

...

1) Should we remove or correct the Mac OS references?

Perhaps we could extract all the pre-OS X references to the Mac OS from
their current locations and charts, segregate them in one sub-section
way at the end of the article, and toward the beginning of the article
state that for the purpose of writing Perl programs, Mac OS X (Darwin)
is to be considered "Unix."

From @ap

* David Golden <xdg@​xdg.me> [2012-09-19 18​:55]​:

I vote "current"

So do I.

It might be worth adding a short preamble paragraph about perl having
supported other platforms, noting that if you write code you still
expect to run on those platforms today then you should refer to their
respective perlport also. Maybe with a list of platforms along with the
stable release in which their support was removed. That way the document
remains comprehensive for users who do need to port to such platforms,
even as it sheds weight over time to avoid burdening everyone else.

Hmm, considering my suggestion for UTS in perl58delta, I see a pattern
emerging here… remove obsolete information to reduce clutter, but leave
brief pointers to the past to remain comprehensive.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

From @nwc10

On Wed, Sep 19, 2012 at 05​:59​:42PM -0700, James E Keenan via RT wrote​:

On Wed Sep 19 09​:48​:42 2012, nicholas wrote​:

Notice that an *other* platform that is mentioned as having non-standard
O_RDONLY etc is Mac OS. This isn't well phrased. It's Mac OS *classic*.
Likewise, the earlier text in there about \r line endings is *classic*,
not Darwin.

...

1) Should we remove or correct the Mac OS references?

Perhaps we could extract all the pre-OS X references to the Mac OS from
their current locations and charts, segregate them in one sub-section
way at the end of the article, and toward the beginning of the article
state that for the purpose of writing Perl programs, Mac OS X (Darwin)
is to be considered "Unix."

Given that Classic is very dead, I don't see any real benefit of this
over Aristotle's suggestion​:

On Thu, Sep 20, 2012 at 10​:00​:14AM +0200, Aristotle Pagaltzis wrote​:

* David Golden <xdg@​xdg.me> [2012-09-19 18​:55]​:

I vote "current"

So do I.

It might be worth adding a short preamble paragraph about perl having
supported other platforms, noting that if you write code you still
expect to run on those platforms today then you should refer to their
respective perlport also. Maybe with a list of platforms along with the
stable release in which their support was removed. That way the document
remains comprehensive for users who do need to port to such platforms,
even as it sheds weight over time to avoid burdening everyone else.

Hmm, considering my suggestion for UTS in perl58delta, I see a pattern
emerging here... remove obsolete information to reduce clutter, but leave
brief pointers to the past to remain comprehensive.

whereas keeping Classic's documentation in does cost us a bit.

Nicholas Clark

From @rjbs

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2012-09-20T04​:00​:14]

It might be worth adding a short preamble paragraph about perl having
supported other platforms, noting that if you write code you still
expect to run on those platforms today then you should refer to their
respective perlport also. Maybe with a list of platforms along with the
stable release in which their support was removed. That way the document
remains comprehensive for users who do need to port to such platforms,
even as it sheds weight over time to avoid burdening everyone else.

Hmm, considering my suggestion for UTS in perl58delta, I see a pattern
emerging here… remove obsolete information to reduce clutter, but leave
brief pointers to the past to remain comprehensive.

I agree with the specific and general both.

--
rjbs

From @jkeenan

On Wed Sep 19 09​:48​:42 2012, nicholas wrote​:

I mailed this to the list at the time, but it got Warnocked

I'd like at least someone else to consider an answer, so here it is as
an RT
ticket. OK, technically someone can close it without commenting, but I
don't
forsee that happening. :-)

I have pushed the commit to blead that deletes all the special case
code for VM/ESA, which should escape in a dev release tomorrow.

Unlike USA, VM/ESA had mentions in perlport.pod.
I have deleted them. I'm not *sure* if this was the right thing to do.
Specifically, I did this​:

@​@​ -1975,14 +1971,14 @​@​ syntax if it is intended to resolve to a valid
path.

=item syscall

-Not implemented. (Win32, VMS, S<RISC OS>, VOS, VM/ESA)
+Not implemented. (Win32, VMS, S<RISC OS>, VOS)

=item sysopen

The traditional "0", "1", and "2" MODEs are implemented with different
numeric values on some systems. The flags exported by C<Fcntl>
(O_RDONLY, O_WRONLY, O_RDWR) should work everywhere though. (S<Mac
-OS>, OS/390, VM/ESA)
+OS>, OS/390)

=item system

Notice that an *other* platform that is mentioned as having non-standard
O_RDONLY etc is Mac OS. This isn't well phrased. It's Mac OS *classic*.
Likewise, the earlier text in there about \r line endings is *classic*,
not Darwin.

So

0) Should perlport represent the current state of Perl portability, or
historical things too?

which probably then answers

1) Should we remove or correct the Mac OS references?

2) Should I have removed the VM/ESA references?

Let's see if we can move this RT to resolution.

0) My reading of the contributions to this RT suggest that
pod/perlport.pod ought to "represent the current state of Perl
portability." If anyone dissents, please speak up now.

1) Which implies that we should remove Mac OS Classic references.

2) Nick, no one responded to you re VM/ESA -- perhaps because no one
knows what that is. (Well, at least *I* don't know what it is.) Which
makes a case for removing the reference. But perhaps you could explain
a bit more about that?

Thank you very much.
Jim Keenan

From @nwc10

On Mon, Jan 14, 2013 at 07​:09​:32PM -0800, James E Keenan via RT wrote​:

2) Nick, no one responded to you re VM/ESA -- perhaps because no one
knows what that is. (Well, at least *I* don't know what it is.) Which
makes a case for removing the reference. But perhaps you could explain
a bit more about that?

I didn't know what it is either. The commit message when I removed it was​:

commit 043fec9
Author​: Nicholas Clark <nick@​ccl4.org>
Date​: Thu Aug 30 18​:25​:53 2012 +0200

  Remove the VM/ESA port.
 
  VM/ESA was a mainframe OS. IBM ended service on it in June 2003. It was
  superseded by Z/VM.

Top Google hit is a wikipedia page that references it in passing. IBM's
own page on it appears to be this​:

http​://www.vm.ibm.com/vm240/

Both suggest that it was replaced by z/VM
z/VM appears to be another IBM OS.

Nicholas Clark

From @jkeenan

On Mon Jan 14 19​:09​:31 2013, jkeenan wrote​:

On Wed Sep 19 09​:48​:42 2012, nicholas wrote​:

I mailed this to the list at the time, but it got Warnocked

I'd like at least someone else to consider an answer, so here it is as
an RT
ticket. OK, technically someone can close it without commenting, but I
don't
forsee that happening. :-)

I have pushed the commit to blead that deletes all the special case
code for VM/ESA, which should escape in a dev release tomorrow.

Unlike USA, VM/ESA had mentions in perlport.pod.
I have deleted them. I'm not *sure* if this was the right thing to do.
Specifically, I did this​:

@​@​ -1975,14 +1971,14 @​@​ syntax if it is intended to resolve to a valid
path.

=item syscall

-Not implemented. (Win32, VMS, S<RISC OS>, VOS, VM/ESA)
+Not implemented. (Win32, VMS, S<RISC OS>, VOS)

=item sysopen

The traditional "0", "1", and "2" MODEs are implemented with different
numeric values on some systems. The flags exported by C<Fcntl>
(O_RDONLY, O_WRONLY, O_RDWR) should work everywhere though. (S<Mac
-OS>, OS/390, VM/ESA)
+OS>, OS/390)

=item system

Notice that an *other* platform that is mentioned as having non-standard
O_RDONLY etc is Mac OS. This isn't well phrased. It's Mac OS *classic*.
Likewise, the earlier text in there about \r line endings is *classic*,
not Darwin.

So

0) Should perlport represent the current state of Perl portability, or
historical things too?

which probably then answers

1) Should we remove or correct the Mac OS references?

2) Should I have removed the VM/ESA references?

Let's see if we can move this RT to resolution.

0) My reading of the contributions to this RT suggest that
pod/perlport.pod ought to "represent the current state of Perl
portability." If anyone dissents, please speak up now.

1) Which implies that we should remove Mac OS Classic references.

Nick, et al.​: Shall we proceed with this?

2) Nick, no one responded to you re VM/ESA -- perhaps because no one
knows what that is. (Well, at least *I* don't know what it is.) Which
makes a case for removing the reference. But perhaps you could explain
a bit more about that?

Nick, et al.​: Shall we proceed with this?

Thank you very much.
Jim Keenan

From @jkeenan

On Sat Jan 25 18​:10​:24 2014, jkeenan wrote​:

On Mon Jan 14 19​:09​:31 2013, jkeenan wrote​:

On Wed Sep 19 09​:48​:42 2012, nicholas wrote​:

I mailed this to the list at the time, but it got Warnocked

I'd like at least someone else to consider an answer, so here it is as
an RT
ticket. OK, technically someone can close it without commenting, but I
don't
forsee that happening. :-)

I have pushed the commit to blead that deletes all the special case
code for VM/ESA, which should escape in a dev release tomorrow.

Unlike USA, VM/ESA had mentions in perlport.pod.
I have deleted them. I'm not *sure* if this was the right thing to do.
Specifically, I did this​:

@​@​ -1975,14 +1971,14 @​@​ syntax if it is intended to resolve to a valid
path.

=item syscall

-Not implemented. (Win32, VMS, S<RISC OS>, VOS, VM/ESA)
+Not implemented. (Win32, VMS, S<RISC OS>, VOS)

=item sysopen

The traditional "0", "1", and "2" MODEs are implemented with different
numeric values on some systems. The flags exported by C<Fcntl>
(O_RDONLY, O_WRONLY, O_RDWR) should work everywhere though. (S<Mac
-OS>, OS/390, VM/ESA)
+OS>, OS/390)

=item system

Notice that an *other* platform that is mentioned as having non-standard
O_RDONLY etc is Mac OS. This isn't well phrased. It's Mac OS *classic*.
Likewise, the earlier text in there about \r line endings is *classic*,
not Darwin.

So

0) Should perlport represent the current state of Perl portability, or
historical things too?

which probably then answers

1) Should we remove or correct the Mac OS references?

2) Should I have removed the VM/ESA references?

Let's see if we can move this RT to resolution.

0) My reading of the contributions to this RT suggest that
pod/perlport.pod ought to "represent the current state of Perl
portability." If anyone dissents, please speak up now.

1) Which implies that we should remove Mac OS Classic references.

Nick, et al.​: Shall we proceed with this?

2) Nick, no one responded to you re VM/ESA -- perhaps because no one
knows what that is. (Well, at least *I* don't know what it is.) Which
makes a case for removing the reference. But perhaps you could explain
a bit more about that?

Nick, et al.​: Shall we proceed with this?

Nick, et. al.​: Shall we proceed with this?

Thank you very much.
Jim Keenan

From @rjbs

* James E Keenan via RT <perlbug-followup@​perl.org> [2014-05-18T10​:26​:55]

Nick, et. al.​: Shall we proceed with this?

Yes, we should eliminate perlport documentation of platforms that are not
supported.

--
rjbs

From @jkeenan

On Mon Sep 15 15​:14​:31 2014, perl.p5p@​rjbs.manxome.org wrote​:

* James E Keenan via RT <perlbug-followup@​perl.org> [2014-05-18T10​:26​:55]

Nick, et. al.​: Shall we proceed with this?

Yes, we should eliminate perlport documentation of platforms that are not
supported.

This ticket was originally filed in September 2012. At various times I suggested we delete references to two OSes which we knew to no longer be supported.

But the consensus of comments has been that we should document which OSes are *currently* supported. That's a significantly different objective, as evidence of active porting to any given OS would be needed to qualify as "currently supported." It's not as simple as "delete references to Mac OS Classic and VM/ESA".

Concretely, that would mean that we'd have to replace the section starting "Supported Platforms (Perl 5.8)" with one starting at 5.20 -- correct?

If so, how do we gather the evidence we need?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

From @rjbs

* James E Keenan via RT <perlbug-followup@​perl.org> [2014-09-15T18​:51​:28]

Concretely, that would mean that we'd have to replace the section starting
"Supported Platforms (Perl 5.8)" with one starting at 5.20 -- correct?

Yes, this seems about right.

My instinct would be to do roughly this​: Document each platform as "supported,
known to be smoked" or "believed to work, no regular smokes" or "believed
broken." We might want a small section for "explicitly allowed to die."

The evidence is basically the appearance of smoke reports or bug reports one
way or another. The first category is the easiest to report. The second and
third are perhaps the most important, because it's the danger zone. They're
pretty easy, because we are stating up front that it's largely a guess. Still,
we can provide evidence in commit messages or the document itself.

--
rjbs