Mailing List Archive

PSC #026, 2021-06-25, minutes
PSC #026 2021-06-25

In attendance: Neil, Nicholas, and Rik

This was our last PSC call with this particular trio. Sad, but time marches ever onward! Rik was on the hook for minutes this week, and was apparently so broken up about the change that he couldn't manage to send them for a full calendar week.

RFCs

The RFC process is moving along with some ups and downs, but we feel like it's generally not a disaster. It needs to continue moving, which means we need to figure out who the RFC editors are. Our first pass answer is: the PSC, plus Nicholas.

We discussed "what are good criteria for future editors":

* demonstrated ability to work with others

* can do "editorial" task even on documents with which the editor disagrees

* has shown reasonable judgement in "what is not a good idea" (as editors are allowed to accept/reject)

* need not be an expert (in design or implementation), but needs to know the limits of own knowledge

* doesn't attempt to argue with decided decisions (without significant new evidence)

* understand perlishness such that they may not agree with every other porter, but their opinions are defensible; that is, some other porter might say "I disagree" but not "what planet are you from?"

Licensing Questions

Discussion of Ry? had us wondering, "Can we package Ry?, under the Boost license?" Rik has asked TPF whether they can get us an opinion from counsel

Other Topics

* C99 — what we want is a document Porting or pod that describes the parts of C we permit. This is already present, ostensibly, in perlhack.pod under "Style". We'll also want to write up the process by which we test things for sufficient portability, which is basically "build a test case that can be smoked everywhere."

* smoke-me branches: the state of these remains (as Jim put it) "complicated"; it would be nice to feel we had someone who was championing an overall fix, but it's also not clear that this can be done by somebody not already very familiar with the situation

* we discussed some MRs (most notably changing how some core libraries use Exporter and dropping the :win32 pseudo-layer); those two are now merged

* we talked about the TPF "Shared Vision of Perl" survey and Neil was to send Andrew Solomon some notes

* I said I'd put together a list of "stuff PSC has said it wants to see happen and need to be carried out", which I have done and will post about shortly.


--
rjbs
Re: PSC #026, 2021-06-25, minutes [ In reply to ]
On Fri, 02 Jul 2021 21:30:14 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> Licensing Questions
>
> Discussion of Ryu had us wondering, "Can we package Ryu, under the Boost license?" Rik has asked TPF whether they can get us an opinion from counsel

I think we should make and document a list of acceptable licenses for
third party code we want to include in Perl. Such licenses should not
burden our users with any additional restrictions or requirements. My
proposed list is (SDPX identifiers):

- 0BSD
- BSD-1-Clause
- BSL-1.0
- Unlicense
- Artistic-1.0-Perl OR GPL-1.0-or-later (aka the perl license)

Note that this list does *not* include MIT or [23]-clause BSD licenses,
because these licenses require distributing binaries with the complete
text of the license and all the copyright notices.

Unfortunately, we have been sloppy about this, so a few MIT/BSD-licensed
files managed to slip into our project (e.g. time64.c). Because of that,
some of our users may be unknowingly violating the license when they
ship Perl binaries. Note that "binaries" also includes scripts wrapped
with PPR, perl2exe and similar tools. We should prevent this from
happening in the future.
Re: PSC #026, 2021-06-25, minutes [ In reply to ]
* Ricardo Signes <perl.p5p@rjbs.manxome.org> [2021-07-02 21:30:14 -0400]:

> PSC #026 2021-06-25
>
> In attendance: Neil, Nicholas, and Rik
>
> This was our last PSC call with this particular trio. Sad, but time marches ever onward! Rik was on the hook for minutes this week, and was apparently so broken up about the change that he couldn't manage to send them for a full calendar week.
>
> RFCs
>
> The RFC process is moving along with some ups and downs, but we feel like it's generally not a disaster. It needs to continue moving, which means we need to figure out who the RFC editors are. Our first pass answer is: the PSC, plus Nicholas.
>
> We discussed "what are good criteria for future editors":
>
> * demonstrated ability to work with others
>
> * can do "editorial" task even on documents with which the editor disagrees
>
> * has shown reasonable judgement in "what is not a good idea" (as editors are allowed to accept/reject)
>
> * need not be an expert (in design or implementation), but needs to know the limits of own knowledge
>
> * doesn't attempt to argue with decided decisions (without significant new evidence)
>
> * understand perlishness such that they may not agree with every other porter, but their opinions are defensible; that is, some other porter might say "I disagree" but not "what planet are you from?"
>

This confuses me a bit.

What is an "editor" and what do you call the original writer of
the RFC? I suppose to me, "editor" is a new term; and I don't know
how to see this as part of the whole process. I also don't know
exactly how the current RFC process is not a more defensible version
of what has happened on p5p in the past.

What do you call someone who has proposed an pre-RFC? And and actual
RFC?

Regarding this role of "editor"; I am confused because this implies
to me, likely incorrectly, that they take an accepted "pre-RFC"
and create the actual RFC that is then subjected actual comments.
If this is not the case, then maybe the term "editor" is not correct.

So how is that supposed to work? Is the RFC proposal process itself
up to date on GH, and can I just trust that? Is that the official
version of the process, or is there another place that will eventually
be created? Or is it that + whatever PSC/"editors" say at any given
time for any given RFC/pre-RFC?

Is anyone responsible for collecting well formed, high quality
comments - or is the email list archives going to be it and future
parties will have to sift out the useful content themselves? One
issue with the "list" being the "place" where opinions are heard
is that, overtime, a great amount of context is lost. Hence my
proposal in the past to accept comments on RFCs officially, only
via PRs on GH. This is so they can be reviewed for completeness,
quality, and proper context. It'd also allow one to ammend their
comments rather than continuing to submit them or assume emails to
p5p would have much impact.

I can't say that the execution of the RFC process thusfar has
provide a consistent example of how things are "supposed" to work.
I hope over time (soon) this situation changes. Consistency is key
to encouraging a stream of well thought of ideas that result in a
continous pipeline of ongoing development activities (that encourage
participation), and ultimately result in the delivery of features
that keep perl's pulse going.

Finally, I'd like to see that as part of an accepted RFC, whomever
is proposing it also provide information on their plan for getting
this work done. This protects the RFC "committee" from getting
overwhelmed; but it also prevents a situation where RFCs devolve
into well written feature requestions. We need to be encouraging
more participation in actual coding and project execution, and the
RFC process has a lot to do with how successfully this need is
addressed.

Cheers,
Brett

ps: last email change for a while and I'll be unsub'ing the other one
probably today

> Licensing Questions
>
> Discussion of Ry? had us wondering, "Can we package Ry?, under the Boost license?" Rik has asked TPF whether they can get us an opinion from counsel
>
> Other Topics
>
> * C99 ? what we want is a document Porting or pod that describes the parts of C we permit. This is already present, ostensibly, in perlhack.pod under "Style". We'll also want to write up the process by which we test things for sufficient portability, which is basically "build a test case that can be smoked everywhere."
>
> * smoke-me branches: the state of these remains (as Jim put it) "complicated"; it would be nice to feel we had someone who was championing an overall fix, but it's also not clear that this can be done by somebody not already very familiar with the situation
>
> * we discussed some MRs (most notably changing how some core libraries use Exporter and dropping the :win32 pseudo-layer); those two are now merged
>
> * we talked about the TPF "Shared Vision of Perl" survey and Neil was to send Andrew Solomon some notes
>
> * I said I'd put together a list of "stuff PSC has said it wants to see happen and need to be carried out", which I have done and will post about shortly.
>
>
> --
> rjbs

--
--
oodler@cpan.org
SDF-EU Public Access UNIX System - http://sdfeu.org