Mailing List Archive

Creating an RFC process for Perl
The PSC would like to create a workable "Request For Comments" process to
handle proposals to change the Perl language.

This builds on the proposal from February, "how to get an idea to a merged
PR", by feeding into a more structured RFC document (and repository) to track
proposals here from the initial idea to shipped implementation, or record
why the idea was rejected.

The proposed RFC repository is https://github.com/Perl/RFCs

I've inlined a plain text version of the "process" document.

The other documents are

motivation - why do we want to do something
template - the RFC template
future - where I want to get to
others - what others do (or did), and what we learn


I'd like to test out this process by feeding an actual "idea" into it,
"live demo" style, to see how it pans out, which I'll do in a separate
message.

Nicholas Clark

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

80% of our feature requests are for changes to the language.
In the past 5 years most work on the parser and tokeniser came from just 5
people. All of them are busy, and none of them are employed by "Perl 5
Porters".

We can't change this mismatch quickly - the reality is that even good ideas
might stall for lack of anyone to implement them, and even where folks are
prepared to help implement their ideas, we will find it hard to mentor many
simultaneously.

Hence we need a process that

* acknowledges this
* emphasises scaling what we have
* enables the originator of an idea to help us as much as possible
* summarises and records discussion and decisions, to iteratively improve
* prioritises proposals, to optimise the value we get from contributors


We'd like to record proposals to improve the language and their status as
"Request For Comment" documents in their own repository under the Perl
organisation on GitHub.


We have a template for what an completed implemented RFC should end up as,
but if all you have is an idea - don't worry, we'll help you get there.
We're still figuring this process out, so for now we're doing it as mail
messages sent to p5p, not as "pull requests" to the RFC repository (or
"issues" on the source repository). This way we can see if the process works
as hoped, and fix the parts that don't.


Not every good idea belongs in the Perl core. Some are better implemented
on CPAN. For some ideas, the RFC process is overkill. And the other way -
for some issues or PRs, the reviewer is going to realise that it's more
complex than it seemed, and needs to become an RFC.

The straight through process is

idea
|
v
mail p5p
|
better | rejected
on <-------?-------> with
CPAN | reasoning
v
Draft RFC
"we think this idea is worth exploring"
(Help us figure out how this will work)
|
v
Provisional RFC
"we think this idea is worth implementing"
(We have a firm idea of what we want to do)
|
v
Accepted RFC
"we think this idea looks viable"
(There is a sane plan for how to do it)
|
v
Implemented RFC
"docs, tests and implementation"
(And we can support it in the future)
|
v
Shipped
In a stable release, subject to "experimental features" process
|
v
Stable
In a stable release, now subject to normal "deprecation" rules



If there are better names, we should change them. The intent is the
important part. Also RFCs might still fail at any point (before "Stable")
and hence become "Rejected". RFCs might also be "Withdrawn" by their
Author(s), or "Superseded" by a newer RFC, so these states and transitions
exist.

Part of this discussion to get from "Draft" to "Accepted" should include
whether a feature guard is needed, concerns on CPAN breakage, security etc,
helping to fill out the "Backwards Compatibility" and "Security
Implications" sections. This is the point where a subject-matter expert may
raise concerns about the proposal, and may effectively veto it. For example,
if you propose a change related to Unicode, and Karl says "it's a really bad
idea for the following reasons", then it's not likely to progress.
Similarly, as the discussion progresses, it may become clear to everyone
that the idea should be rejected. We might figure out that the idea is
better implemented on CPAN, that something we thought was better on CPAN
should return as an RFC. (eg try/catch and Moose/Moo leading to Cor).

Any RFC (before merging) can be marked "Deferred" if work has paused, or if
they have no-one implementing them. RFCs have at least on *Author*, who acts
as champion for the idea, and ideally writes documentation and tests.
"Accepted" RFCs should have a core team member as a *Sponsor*, who acts as
mentor and point of contact. If the *Author* can't implement their idea
alone, and no-one else volunteers, then the PSC will try to find someone to
implement an "Accepted" RFC, but this may not be possible, and the RFC will
stall.

The PSC approves the transitions Draft => Provisional => Accepted
but will actively seek opinion from people familiar with the subject.

The transition from Accepted => Implemented is made by merging the PR that
implements the RFC. At least one reviewer should be neither the Author nor
the Sponsor. (Even if all that they can say is that the other two are *the*
subject experts and that it all looks good.)

There is an ongoing discussion how how we decide whether to merge a PR, with
the latest proposal being:

* After an appropriate period, if there are not strong disagreements, and
the PSC haven't rejected it, a committer will merge the PR.
* Trivial or obviously-correct changes may be committed directly. I.e., the
appropriate length is sometimes zero.
* If objections are raised, they need to be addressed (meaning "clearly
replied to", and for an RFC the reasoning recorded in "Rejected Ideas")
* If the objection is from a subject matter expert, you need to come to an
agreement.
* If the PR stalls, ping the PSC for adjudication. We expect this will be
quite rare either you should have gone through the proposal process, or
it's straightforward.
* PRs from non-committers are expected to have more scrutiny.

What's an appropriate period?

* For "I think this is right but want to give a chance for comments", a
couple of days is probably fine.
* For "this is a significant change that I could really use feedback on," a
week or more is probably best, and the PR should probably be flagged to
the list as wanting attention.
* The later in the release cycle, the stricter we should be with ourselves.

Don't panic: changes can be reverted.


What needs an RFC? What can just be a PR?

There's no obvious answer, because there's no clear cut off, and there never
will be, even when the process is "out of beta". For now we think we should
use RFCs for

1 Language changes (feature changes to the parser, tokeniser)
2 Command line options
3 Adding/removing warnings (entries in perldiag.pod)
4 Significant changes to when an existing warning triggers

A case that came up recently was moving the reporting of an error from
runtime to compile time (GH #18785). We think that this wouldn't warrant an
RFC (just regular code review) because no correct code should be relying on
when an error is reported. However, there is still a judgement call here, as
it would *not* be correct for constant folding to report errors (such as
divide by zero) as this might only happen on some platforms as a side effect
of the values of constants, and those expressions were unreachable on those
platforms.
Re: Creating an RFC process for Perl [ In reply to ]
Generally good Idea

I'd suggest structure:
RFC-0001/
RFC.md
examples/
including different languages
tests/
author of RFC can be able to provide test cases even if not able to
deliver required C code

Workflow to solve - when only part RFC is implemented (eg due dependencies
on another RFC)
Can it be like "perl v5.42 implements: RFC-0042.1 - xxx" ?

Ad initial proposal
it should be browsable and should have capability of "comment per line",
for example github pull requests
with their comments ... idea: what about two repositories? RFC (for
accepted) and RFC-draft ?

Brano
Re: Creating an RFC process for Perl [ In reply to ]
I like the proposed rfc process and the proposed syntax extension.

So I'm inclined to just say:

RFC process: +1
RFC 0001: +1

Is that a helpful addition to the "?" stage indicated in the process diagram?


On 6/8/21, Branislav Zahradník <happy.barney@gmail.com> wrote:
> Generally good Idea
>
> I'd suggest structure:
> RFC-0001/
> RFC.md
> examples/
> including different languages
> tests/
> author of RFC can be able to provide test cases even if not able to
> deliver required C code
>
> Workflow to solve - when only part RFC is implemented (eg due dependencies
> on another RFC)
> Can it be like "perl v5.42 implements: RFC-0042.1 - xxx" ?
>
> Ad initial proposal
> it should be browsable and should have capability of "comment per line",
> for example github pull requests
> with their comments ... idea: what about two repositories? RFC (for
> accepted) and RFC-draft ?
>
> Brano
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to doom+unsubscribe@kzsu.stanford.edu.
>
Re: Creating an RFC process for Perl [ In reply to ]
On Tue, Jun 08, 2021 at 08:24:53PM +0200, Branislav Zahradn?k wrote:
> Generally good Idea
>
> I'd suggest structure:
> RFC-0001/
> RFC.md
> examples/
> including different languages
> tests/
> author of RFC can be able to provide test cases even if not able to
> deliver required C code

I was certainly expecting that the author can provide test cases, but I was
assuming that this would happen as part of the implementation branch.

I *think* that examples fit better inline in the RFC document. But we have
a sample size of zero currently, so I might well be wrong.

> Workflow to solve - when only part RFC is implemented (eg due dependencies
> on another RFC)
> Can it be like "perl v5.42 implements: RFC-0042.1 - xxx" ?

Good question. For a slightly different case,
https://www.python.org/dev/peps/pep-0001/ says

The more focused the PEP, the more successful it tends to be. The
PEP editors reserve the right to reject PEP proposals if they
appear too unfocused or too broad. If in doubt, split your PEP
into several well-focused ones.


So if an RFC can't be implemented in whole, then I think the right thing to
do is to split the RFC in to several new ones, and mark that the old RFC is
superseded by the new RFCs.

We have enough fun with non-integer versions in Perl code - I don't think
that I'd like to have it for documentation too :-)


> Ad initial proposal
> it should be browsable and should have capability of "comment per line",
> for example github pull requests

I'd like to get to that, but right now

1) We don't even tend to do "comment per line" code review that well on GitHub
2) We *can* do "comment perl line" review in e-mail messages
(this is the workflow that git itself uses, and is what perl had to use
before the switch to GitHub - mailed patch submissions)

It will make sense to use PRs (or suchlike) once "we" are in a place where
initial ideas are submitted formatted as draft RFCs, but right now we aren't
there.

1) We don't have a proven working RFC format - this is still fluid.
2) The style of discussion on the list so far suggests that "we" aren't that
good at discussion about features, independent of what format we use.

"We" need to get better at point 2 before we can "firm up" our process and
let it run unsupervised. And it might look like it's generating a lot of
useless noise, but I think that a public bootcamp in figuring out how to
handle feature discussion is the only way that we're actually going to get
better at it.

> with their comments ... idea: what about two repositories? RFC (for
> accepted) and RFC-draft ?

That risks loosing history when "moving" an RFC from one to the other.

(Yes, you can take various approaches with git commands to merge in the
history of one file, but it's not trivial, not something I'd be comfortable
automating, and feels like admin work - admin work is something I'm trying
really hard to minimise)

Also "issues" and "PR" numbers are only unique within a repository - if
people are "embracing" GitHub and using GitHub style references to the
IDs in their commit messages, then these are going to "break" if the
commit is migrated to a different repository.

I don't see any real advantage in having multiple repositories over having
multiple directories. And I'm not even sure if we need directories - what
matters in the index documents.


Keep in mind that this isn't the *finished* RFC process - I'm trying to find
a way to

1) introduce an RFC process where there was none before
2) where it's clear that most of the ideas are good but hard to implement
3) where there is a backlog if ideas to "catch up on"
4) where we are "under resourced" on folks actually able to implement things

It is "If I were you sir, I wouldn't start from here".

Your suggestions look good as a possible "end" goal, but we're not going to
get there in one step.

Nicholas Clark
Re: Creating an RFC process for Perl [ In reply to ]
Nicholas,
I think it's high time that perl's print() function embraced dragon4-type
[1] formatting of floating point values.
Admittedly, I won't be surprised if this never happens, but I do think it
should formally be placed on the TODO list ... and then ... who knows ...

Given that I probably won't ever be in a position to provide a PR that
implements this, should I therefore refrain from making such an RFC ?

Cheers,
Rob

[1] It doesn't have to be dragon4 - it could be grisu3 or ryu. However, it
has to be something that would work with all 3 of perl's nvtypes, and I'm
not sure that grisu3 or ryu will scale to "long double" and "__float128"
nvtypes.
You, Nicholas, might have a better knowledge of that.
I should add that I've never written an implementation of dragon4 - mainly
because I haven't yet managed to come to grips with that procedure, as
presented in tables 5 to 13 of "How to Print FloatingPoint Numbers
Accurately" by Steele and White.
However, in my Math::MPFR module, I have implemented tables 3 and 4 (from
the same Steele and White paper) such that the desired dragon4-type
presentation of these values is provided for all 3 nvtypes, including the
"DoubleDouble" long double nvtype.
This implementation (which I've called "nvtoa") uses the gmp library to
handle the arbitrary precision integer arithmetic. If the nvtype is
"DoubleDouble", nvtoa() also requires the mpfr library.
It's about 3 to 4 times more costly (in time) than perl's sprintf(), but it
works reliably AFAIK.
Math::MPFR also provides dragon4-type presentation of arbitrary precision
floating point values via the "mpfrtoa" function.
And ... there's more ... Math::MPFR additionally provides a grisu3
implementation (named "doubletoa") - but that's just a copy'n'paste of
grisu3, and applies only to nvtype of 'double'.
Isuspect that talented and gifted programmers might see my implementations
as being rather pedestrian ... but, AFAIK, that's all we currently have wrt
Perl.
Re: Creating an RFC process for Perl [ In reply to ]
Hi Rob,
> Given that I probably won't ever be in a position to provide a PR that implements this, should I therefore refrain from making such an RFC ?

Two points:

1. Just because you can’t implement something, doesn’t mean you shouldn’t suggest it. We expect lots of ideas to come from people who are using Perl every day, regardless of whether they can hack on the core. But even if an idea is universally liked, it still needs someone to implement it, and we don’t have too many of those.
2. The first step is to post your idea to p5p, and only move to an RFC if it survives any discussion there.

Neil
Re: Creating an RFC process for Perl [ In reply to ]
I *think* that examples fit better inline in the RFC document. But we have
> a sample size of zero currently, so I might well be wrong.
>

Ok, so let's try. I'm preparing RFC "New programming paradigm for perl -
context oriented programming".
I'd like to discuss it anyway at some point so why not to use it to test
and tune RFC process as well?

https://github.com/happy-barney/perl-poc/pull/2
Re: Creating an RFC process for Perl [ In reply to ]
2021-6-9 21:11 Neil Bowers <neilb@neilb.org> wrote:

> Hi Rob,
>
> Given that I probably won't ever be in a position to provide a PR that
> implements this, should I therefore refrain from making such an RFC ?
>
>
> Two points:
>
> 1. Just because you can’t implement something, doesn’t mean you
> shouldn’t suggest it. We expect lots of ideas to come from people who are
> using Perl every day, regardless of whether they can hack
>
>
Paul is active in adding grammar and can actually implement it.

I feel that he is the only one who can do that now in the Perl Core team
considering the situation up to now.

If we want to add grammar, we need to search for the point that Paul's
motivation and our consensus matches .
Re: Creating an RFC process for Perl [ In reply to ]
On Thu, Jun 10, 2021 at 08:26:42AM +0900, Yuki Kimoto wrote:
> 2021-6-9 21:11 Neil Bowers <neilb@neilb.org> wrote:
>
> > Hi Rob,
> >
> > Given that I probably won't ever be in a position to provide a PR that
> > implements this, should I therefore refrain from making such an RFC ?
> >
> >
> > Two points:
> >
> > 1. Just because you can’t implement something, doesn’t mean you
> > shouldn’t suggest it. We expect lots of ideas to come from people who are
> > using Perl every day, regardless of whether they can hack
> >
> >
> Paul is active in adding grammar and can actually implement it.
>
> I feel that he is the only one who can do that now in the Perl Core team
> considering the situation up to now.
>
> If we want to add grammar, we need to search for the point that Paul's
> motivation and our consensus matches .

Adding grammar isn't all that hard*, I've done it in limited ways to
fix a bug.

Nicholas didn't seem to have much problem in producing the grammar
changes for his foreach change.

The hard part is deciding the behaviour to implement and the
lack of process in actually getting it into perl.

This RFC process should help with both parts, since we didn't really
have a process beyond "commit if you have a commit bit".

Tony

* relative to any other code having to deal with the OP tree and internals
Re: Creating an RFC process for Perl [ In reply to ]
On Thu, 10 Jun 2021 10:35:33 +1000
Tony Cook <tony@develop-help.com> wrote:

> Adding grammar isn't all that hard*, I've done it in limited ways to
> fix a bug.
>
> Nicholas didn't seem to have much problem in producing the grammar
> changes for his foreach change.
>
> The hard part is deciding the behaviour to implement and the
> lack of process in actually getting it into perl.
>
> This RFC process should help with both parts, since we didn't really
> have a process beyond "commit if you have a commit bit".
>
> Tony
>
> * relative to any other code having to deal with the OP tree and internals

Anyone who wants to learn how to implement a new Perl feature should
read LeoNerd's tutorial:

http://leonerds-code.blogspot.com/2021/02/writing-perl-core-feature.html
Re: Creating an RFC process for Perl [ In reply to ]
On Wed, Jun 9, 2021 at 10:10 PM Neil Bowers <neilb@neilb.org> wrote:

Two points:
>
> 1. Just because you can’t implement something, doesn’t mean you
> shouldn’t suggest it. We expect lots of ideas to come from people who are
> using Perl every day, regardless of whether they can hack on the core. But
> even if an idea is universally liked, it still needs someone to implement
> it, and we don’t have too many of those.
> 2. The first step is to post your idea to p5p, and only move to an RFC
> if it survives any discussion there.
>
> Nicholas has recently provided a Ryu implementation - see
https://github.com/MoarVM/MoarVM/pull/1472 .
IIUC, this will be included in Raku, following review.
(That's sort of why I addressed my post to Nicholas - but knowing quite
well that others would feel welcome to make a comment, as they should.)

I'll prepare and submit a case to p5p, as per your second point ... and see
where that leads.

Thanks Neil !

Cheers,
Rob
Re: Creating an RFC process for Perl [ In reply to ]
2021-6-10 9:35 Tony Cook <tony@develop-help.com> wrote:

>
> Adding grammar isn't all that hard*, I've done it in limited ways to
> fix a bug.
>

OK. I understand that Tony is not difficult to implement new features.


> The hard part is deciding the behaviour to implement and the
> lack of process in actually getting it into perl.
>
> This RFC process should help with both parts, since we didn't really
> have a process beyond "commit if you have a commit bit".
>
>
OK. It's a good idea to try something small to see if the process works.
Re: Creating an RFC process for Perl [ In reply to ]
On Thu, Jun 10, 2021 at 12:07:54PM +1000, sisyphus wrote:
> On Wed, Jun 9, 2021 at 10:10 PM Neil Bowers <neilb@neilb.org> wrote:
>
> Two points:
> >
> > 1. Just because you can’t implement something, doesn’t mean you
> > shouldn’t suggest it. We expect lots of ideas to come from people who are
> > using Perl every day, regardless of whether they can hack on the core. But
> > even if an idea is universally liked, it still needs someone to implement
> > it, and we don’t have too many of those.
> > 2. The first step is to post your idea to p5p, and only move to an RFC
> > if it survives any discussion there.
> >
> > Nicholas has recently provided a Ryu implementation - see
> https://github.com/MoarVM/MoarVM/pull/1472 .
> IIUC, this will be included in Raku, following review.
> (That's sort of why I addressed my post to Nicholas - but knowing quite
> well that others would feel welcome to make a comment, as they should.)

I don't think that I need to duplicate anything I already wrote there.

"Implementation" and "Licensing" would be the parts that need adding to.


The output of Ry? was not in the format that MoarVM needed.
(It generates something like '1E-4' - what is needed is '1e-04', etc)

So I wrote C code to massage that into the string format needed.*

(I think that for Grisu3, the output also needed changing, but when Zoffix
added Grisu3 it seems that he made the changes in a local copy of the
Grisu3 C code. I thought it clearer to keep the upstream code "virgin"
and do the fixups as "post-processing", so I took this different approach.)

Given that it's submitted to MoarVM, it's implicitly licensed as "Artistic
License 2". I don't *think* that it's acceptable to *just* incorporate AL2
code into a GPL2|AL1 project. So if it turns out in the future we also need
that code here

1) Explicitly as copyright holder I'm fine with that code being used here

and

2) More generally, I'm fine with any code I wrote that is submitted to a
project with an AL2 licence being re-used (and re-licensed) as dual
GPL2|AL1 for use in a dual GPL2|AL1 project
(ie "same terms as Perl itself")


Looking a bit further at the Ry? repository I realised that there were
a couple of things to discuss on the PSC, so I stuck it on the agenda for
Friday, and I wasn't going to comment until then. Meanwhile, Neil also
replied...

> I'll prepare and submit a case to p5p, as per your second point ... and see
> where that leads.

Thanks.

Also "changing the internals of how floating point is outputted" isn't
*exactly* covered by the initial list of "things that need an RFC". But it
does feel like the sort of thing that should be an RFC. So thanks for
finding something useful that we missed.

Nicholas Clark

* Co-incidentally I happened to use piece of paper with the notes for that
code on it as part of lighting the barbecue at the weekend. The code is
done, and it and the comments covered everything in the notes...
Re: Creating an RFC process for Perl [ In reply to ]
A quick thought while it's in my mind (and I hope to expand on this
later - someone please prod me if I don't in the next few days)

There needs to be an optional section in the template for "scope for
later expansion". E.g. if I had written try/catch as an RFC I'd
definitely have explained "Future expansion: typed catch". It's useful
to be able to say "I'm definitely not addressing this problem *now*,
but I am leaving this hole for a future time".

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Creating an RFC process for Perl [ In reply to ]
On Thu, Jun 10, 2021 at 04:50:00PM +0100, Paul "LeoNerd" Evans wrote:
> A quick thought while it's in my mind (and I hope to expand on this
> later - someone please prod me if I don't in the next few days)
>
> There needs to be an optional section in the template for "scope for
> later expansion". E.g. if I had written try/catch as an RFC I'd
> definitely have explained "Future expansion: typed catch". It's useful
> to be able to say "I'm definitely not addressing this problem *now*,
> but I am leaving this hole for a future time".

You're right - thanks for thinking about the proposed process in the context
of "how would I write an RFC for X". It was also clear that we needed this
sort of section from the `foreach` discussions. I don't happen to have a
parallel universe to test this theory out in, but I think that it was the
right "plan" to introduce both the proposed RFC process *and* a proposed
RFC at the same time, instead of the alternative of just doing "here's a
proposed process" first.

Anyway, I am astounded to discover that in all the detail covered in PEP1
there isn't anything about this (so nothing to steal). I know that the
Open Group online man pages have a "Future Directions" section, so I was
wondering about that name, but it turns out that PHP have it in their
template as "Future Scope" -- https://wiki.php.net/rfc/template
which I thought was better, so I added this to the template:

## Future Scope

Were there any ideas or variations considered that seemed reasonable
follow-ons from the initial suggestions, that we don't need to do now,
but want to revisit in the future? If there are parts of the design
marked as "intended for future expansion", then give an idea here of
what direction is planned.


As for everything else, I'm not hung up on the names (or the details) - if
there's a better name we should use that instead.

Nicholas Clark
Re: Creating an RFC process for Perl [ In reply to ]
On Thu, Jun 10, 2021 at 09:12:11AM +0000, Nicholas Clark wrote:

> > On Wed, Jun 9, 2021 at 10:10 PM Neil Bowers <neilb@neilb.org> wrote:
> >
> > Two points:
> > >
> > > 1. Just because you can’t implement something, doesn’t mean you
> > > shouldn’t suggest it. We expect lots of ideas to come from people who are
> > > using Perl every day, regardless of whether they can hack on the core. But
> > > even if an idea is universally liked, it still needs someone to implement
> > > it, and we don’t have too many of those.
> > > 2. The first step is to post your idea to p5p, and only move to an RFC
> > > if it survives any discussion there.

> > https://github.com/MoarVM/MoarVM/pull/1472 .

> I don't think that I need to duplicate anything I already wrote there.

Three things that weren't mentioned there that are relevant

1) Ry? is actually dual licensed Apache 2 | Boost
2) In theory https://github.com/ulfjack/ryu/blob/master/ryu/Makefile
and the C are portable - in practice there was at least one 32 bit Linux
platform that I couldn't built the entire tree on. I forget which, and I
don't want to go for an exhaustive search, but I *think* that it was the
128 bit version not building "everywhere"
3) The 64 bit version *is* portable - I've just built MoarVM etc with it on
Sparc Solaris with Sun's compiler. (So an exacting 64 bit big endian
system)


So at least some of it likely is totally portable for us. But I suspect we
can't do long doubles and quad on some platforms, and maybe *no-one* has
tested quad on big endian platforms before. Or VMS :-)

(let alone QNX or some of the other fun things BinGOs can throw at us)

> Looking a bit further at the Ry? repository I realised that there were
> a couple of things to discuss on the PSC, so I stuck it on the agenda for
> Friday, and I wasn't going to comment until then. Meanwhile, Neil also
> replied...

The summary is - "go for it".

So at to the RFC process that we are beta testing...

* You mailed an idea to p5p
* No-one has raised any show-stopper problems
* "we think this idea is worth exploring"
* So please submit a Draft RFC - the ID 0002 is now yours
* I guess you are "Author" and I am "Sponsor"

I'm not quite sure *how* that's going to work, as you're now the brave first
tester of this, and the template is really for language changes. It's at

https://github.com/Perl/RFCs/blob/master/docs/template.md

1) I don't know if all the sections are really relevant here.
2) You might need to add some more if they seem relevant

I guess try to sketch out the contents for Preamble, Motivation, Rational
and Backwards Compatibility, and mail that back to the list. But if that's a
daft idea, or you get stuck, mail back with why it's not working out and we
(well, at least I) will try to help.

Nicholas Clark
Re: Creating an RFC process for Perl [ In reply to ]
On Fri, Jun 11, 2021 at 2:34 PM Nicholas Clark <nick@ccl4.org> wrote:

> But I suspect we
> can't do long doubles and quad on some platforms, and maybe *no-one* has
> tested quad on big endian platforms before. Or VMS :-)

128-bit IEEE long doubles (also called X_FLOAT in the
DEC/Compaq/HP/HPE/VSI world) are supported on Tru64 Alpha, OpenVMS
Alpha, Linux Alpha, and OpenVMS I64. OpenVMS x86_64 is supposed to
appear any day now in an early adopter's kit, but I don't know yet
whether its long doubles will be the 80-bit kind common on x86
platforms or one of the 128-bit types.

A few years ago Jarkko did a bunch of work classifying long doubles
(as well as other float formats) so in principle I think we have names
for where all the bits are located plus some other quirks for all the
different flavors. The entry for longdblkind in Porting/Glossary and
the sizable chunk of real estate occupied by LONG_DOUBLEKIND in perl.h
would be starting places for prior art that may be helpful in asking
"just what kind of long double do we get on platform X?" Or maybe we
don't care about platforms as long as the formatting under discussion
here supports the 10 types Jarkko identified.

Apologies if this is all covered by the libraries mentioned up-thread;
they are all names that are new to me and I have not found the time to
educate myself yet.
Re: Creating an RFC process for Perl [ In reply to ]
On Sat, Jun 12, 2021 at 5:33 AM Nicholas Clark <nick@ccl4.org> wrote:

[snip]

The summary is - "go for it".
>
> So at to the RFC process that we are beta testing...
>
> * You mailed an idea to p5p
> * No-one has raised any show-stopper problems
> * "we think this idea is worth exploring"
> * So please submit a Draft RFC - the ID 0002 is now yours
> * I guess you are "Author" and I am "Sponsor"
>
> I'm not quite sure *how* that's going to work, as you're now the brave
> first
> tester of this, and the template is really for language changes. It's at
>
> https://github.com/Perl/RFCs/blob/master/docs/template.md
>
> 1) I don't know if all the sections are really relevant here.
> 2) You might need to add some more if they seem relevant
>
> I guess try to sketch out the contents for Preamble, Motivation, Rational
> and Backwards Compatibility, and mail that back to the list. But if that's
> a
> daft idea, or you get stuck, mail back with why it's not working out and we
> (well, at least I) will try to help.
>
>
Thanks Nicholas.
I'll start working on this, and see how it goes. (It might take me a day or
3.)

Cheers,
Rob
Re: Creating an RFC process for Perl [ In reply to ]
??????? Original Message ???????

On Wednesday, June 9th, 2021 at 7:56 PM, Tomasz Konojacki <me@xenu.pl> wrote:

> On Thu, 10 Jun 2021 10:35:33 +1000
>
> Tony Cook tony@develop-help.com wrote:
>
> > Adding grammar isn't all that hard*, I've done it in limited ways to
> >
> > fix a bug.
> >
> > Nicholas didn't seem to have much problem in producing the grammar
> >
> > changes for his foreach change.
> >
> > The hard part is deciding the behaviour to implement and the
> >
> > lack of process in actually getting it into perl.
> >
> > This RFC process should help with both parts, since we didn't really
> >
> > have a process beyond "commit if you have a commit bit".
> >
> > Tony
> >
> > - relative to any other code having to deal with the OP tree and internals
>
> Anyone who wants to learn how to implement a new Perl feature should
>
> read LeoNerd's tutorial:
>
> http://leonerds-code.blogspot.com/2021/02/writing-perl-core-feature.html

Which is precisely how we got into this trim mess. That and an attempt to call ones bluff. Probably not the best way to handle things in the future.

I'd like to see an RFC process that also allows for people to suggest things that don't know how to implement them, as Neil has suggested. But bonus points if they are onboard to help and learn.

What we have here is an opportunity to create a formalized process. It's also an opportunity to build this process out as a series of RFCs (for the RFC, yes).

As such, we should be on the look out for the different kinds of RFCs that get proposed. Furthermore, we should be mindful of the motivations of the RFC and what is being asked. I get it; this is still embryonic, but has huge potential to bring great improvements to perl, Perl, and our processes. We must be mindful of dirty pool and saying "NO" in its many forms. The process must be "fair", meaning that each RFC gets its fair shake. I also would love to see the PSC or whomever picks some "themes" or "areas" for RFCs. This is also a great target for "grand challenges" - e.g., "2022 is the year of <<doing something>> with <<some area of perl/Perl>>'. Just because the RFCs come from the wild doesn't mean our overlords can suggest a focus area or more.

In addition to having a "nomination" and a "sponsor" (or second), there be a process by which less-skilled or seasoned individuals who wish to participate in implementation be given an opportunity to do so - especially if they are the one who proposed it. Think of it as GSC but for Perl and all year long. Does it need a group of seasoned Obi Wans or Luke Skywalkers to mentor? Yes. I think we have a few of those, and with the right amount of beer or appeals to cementing their legacies, maybe they will be cajoled into fulfilling this role.

We don't need the reason of "we have no one to implement your idea" ever be a reason to not do something. This would necessary require a volunteer mentor to assist such individuals. But if the spirit of this idea is followed, then you'll simultaneous permit good ideas "from the field" to come to light and also develop new classes and generations of contributors.

Cheers,
Brett
Re: Creating an RFC process for Perl [ In reply to ]
On Sat, Jun 12, 2021 at 01:44:00AM +0000, mah.kitteh via perl5-porters wrote:
> ??????? Original Message ???????
>
> On Wednesday, June 9th, 2021 at 7:56 PM, Tomasz Konojacki <me@xenu.pl> wrote:
>
> > On Thu, 10 Jun 2021 10:35:33 +1000
> >
> > Tony Cook tony@develop-help.com wrote:
> >
> > > Adding grammar isn't all that hard*, I've done it in limited ways to
> > >
> > > fix a bug.
> > >
> > > Nicholas didn't seem to have much problem in producing the grammar
> > >
> > > changes for his foreach change.
> > >
> > > The hard part is deciding the behaviour to implement and the
> > >
> > > lack of process in actually getting it into perl.
> > >
> > > This RFC process should help with both parts, since we didn't really
> > >
> > > have a process beyond "commit if you have a commit bit".
> > >
> > > Tony
> > >
> > > - relative to any other code having to deal with the OP tree and internals
> >
> > Anyone who wants to learn how to implement a new Perl feature should
> >
> > read LeoNerd's tutorial:
> >
> > http://leonerds-code.blogspot.com/2021/02/writing-perl-core-feature.html
>
> Which is precisely how we got into this trim mess. That and an attempt to call ones bluff. Probably not the best way to handle things in the future.

I'm not sure what you're meaning here.

The RFC process we're trialling *would* avoid one huge part of the trim mess -
it would have exposed the entire problem of revisiting the question of
"in place" vs "returning a value" *after* that decision seemed to have been
settled, and hence it was fair to work on an implementation.

The problem effectively is attempting to re-legislate something that is
already decided.

Much like it *is* decided that (at least) an efficient trim function belongs
in the core, and it is not helpful to try to re-open that discussion to get
a different answer.

> I'd like to see an RFC process that also allows for people to suggest things that don't know how to implement them, as Neil has suggested. But bonus points if they are onboard to help and learn.

I believe that that is exactly what the process we are trialling can do.

> What we have here is an opportunity to create a formalized process. It's also an opportunity to build this process out as a series of RFCs (for the RFC, yes).

No, as I wrote in https://github.com/Perl/RFCs/blob/master/docs/others.md

PEPs and TIPs are both used both for code improvements and process
improvements. This conflation seems awkward - it requires a
special status ("Active") for process related PEPs/TIPs, and many
of the sections needed for feature changes are irrelevant for
process changes. It also means that the official document for the
process itself is the change document for the process, not the
procedure document. I think this is a bad idea and we should not
imitate it. PHP's RFCs only cover code. I like this better, but I
think we can "borrow" more of the detail from the Python and TCL
approach than from PHP's.

It does not make sense to use the same style of RFC to describe process as
to describe code.

> As such, we should be on the look out for the different kinds of RFCs that get proposed. Furthermore, we should be mindful of the motivations of the RFC and what is being asked. I get it; this is still embryonic, but has huge potential to bring great improvements to perl, Perl, and our processes. We must be mindful of dirty pool and saying "NO" in its many forms. The process must be "fair", meaning that each RFC gets its fair shake. I also would love to see the PSC or whomever picks some "themes" or "areas" for RFCs. This is also a great target for "grand challenges" - e.g., "2022 is the year of <<doing something>> with <<some area of perl/Perl>>'. Just because the RFCs come from the wild doesn't mean our overlords can suggest a focus area or more.

I doubt that declaring something expecting movement is helpful.
In https://github.com/Perl/RFCs/blob/master/docs/motivation.md

There's a massive disparity between how many ideas we have and how
many people we have to even mentor others, let alone implement
things.

To get out of this hole, we need an approach that acknowledges
this and emphasises scaling up and out with what we have, instead
of pretending that we're short on ideas and long on under-used
talent.

Declaring the 2022 the "year of foozles" might produce lots of suggestions
about foozles, but it won't increase the number of folks working on them.
*Also*, strictly, "2022" doesn't work as our cycle is roughly June-June.
2022.5 doesn't quite have that ring to it.

> In addition to having a "nomination" and a "sponsor" (or second), there be a process by which less-skilled or seasoned individuals who wish to participate in implementation be given an opportunity to do so - especially if they are the one who proposed it. Think of it as GSC but for Perl and all year long. Does it need a group of seasoned Obi Wans or Luke Skywalkers to mentor? Yes. I think we have a few of those, and with the right amount of beer or appeals to cementing their legacies, maybe they will be cajoled into fulfilling this role.

It's "Author" and "Sponsor" - have you read it before commenting on it?

The explicit intent is that the "Author" need not be skilled in the internals
of Perl: https://github.com/Perl/RFCs/blob/master/docs/future.md

The Author is the champion for the RFC. Their motivation and enthusiasm
to have the feature successfully implemented and shipped drives the
process. Their task is to eliminate each "lowest hanging excuse" in turn
to get to shipping code. They are responsible for

* seeking input
* shepherding discussion to some sort of consensus (or appealing to the
PSC to resolve an impasse)
* ensuring all sections in the RFC are complete (working with
implementers and others as necessary)

I looked at the git history of the trim branch and this is pretty much
exactly how the work was divided up. LeoNerd *just* did the coding.
Scott Baker wrote the tests, wrote the documentation, and did all the
cleanup to get things into a presentable state. I think he also handled
shepherding the discussions, but I've not gone to check that.

This split maximises the time we have from our limited number of skilled
contributors, and also helps get more people familiar with more parts of
the core.

It's already what's being proposed.

> We don't need the reason of "we have no one to implement your idea" ever be a reason to not do something. This would necessary require a volunteer mentor to assist such individuals. But if the spirit of this idea is followed, then you'll simultaneous permit good ideas "from the field" to come to light and also develop new classes and generations of contributors.

https://github.com/Perl/RFCs/blob/master/docs/process.md

We have a template for what an completed implemented RFC should end up
as, but if all you have is an idea - don't worry, we'll help you get
there.


Any RFC (before merging) can be marked "Deferred" if work has paused, or
if they have no-one implementing them. RFCs have at least on Author, who
acts as champion for the idea, and ideally writes documentation and
tests. "Accepted" RFCs should have a core team member as a Sponsor, who
acts as mentor and point of contact. If the Author can't implement their
idea alone, and no-one else volunteers, then the PSC will try to find
someone to implement an "Accepted" RFC, but this may not be possible,
and the RFC will stall.


ie it is planned (and designed) such that we can "Accept" an RFC without
having anyone down to implement it.

it is intended that we can accept good *ideas* from anyone and turn them
into RFCs.


It is clear that you haven't actually read https://github.com/Perl/RFCs
before "commenting" on it, because you are making specific criticisms
about missing things are present.

*Had* you read it, you would have been criticising why they weren't the
best way to achieve the shared goal.


Thank you for wasting my time.


Nicholas Clark
Re: Creating an RFC process for Perl [ In reply to ]
On Sat, Jun 12, 2021 at 07:12:51AM +0000, Nicholas Clark wrote:

> Thank you for wasting my time.

My statement here was inappropriate. It's not a good example from anyone,
let alone someone supposed to be showing leadership. Brett replied privately
to me, politely and without any sarcasm or other failings that I made in
public. I commend him on keeping a cooler head under pressure than I do.

Everyone makes mistakes. (Clearly I just demonstrated this)

I don't want people to think that mistakes, unpopular opinions, or anything
else is not tolerated, and hence be afraid to contribute. That would be the
death of discussion, and the resulting groupthink would be ultimately kill
Perl.

However there are four or five individuals who seem to have more confidence
in their opinions than their reasoning should warrant, and often generate a
large amount of list traffic with a lower density of useful input. These
messages take considerable time and patience to meaningfully respond to. At
times, about 1% of the subscriber base can generate 10% of the list volume,
which spreads the actionable content very thin. That this keeps happening
gets extremely frustrating.

To be clear - I'm not saying that anyone's contribution is worthless. Far
from it - I know that several individuals who at times frustrate myself and
others have also had useful insights that no-one else has had, or reported
bugs where the reaction was "oops, that's not good, we had better fix that
quickly". When names are mentioned in private conversations, I make sure
that I defend their virtues too, and am clear that I don't want to cut
*anyone* out.

It feels that to be on the PSC you're expected to have the patience of a
saint, the wisdom of Solomon, ... a bunch more clich?s ... infinite time and
infinite stamina. Whereas, like Soylent Green, the PSC is made of people.
Just 3 people. It's like we're three bartenders in a large rowdy bar, trying
to maintain the atmosphere and keep everyone happy, where it always seems
like it's on the cusp of a fist fight breaking out. If that's your unpaid
side hustle 7 days a week, it can get draining.

Humans can't live up to these expectations, and eventually their patience
frays.

On balance, I still believe that I am net force for good, and anyone reading
the list archives would reach the same conclusion.

Nicholas Clark
Re: Creating an RFC process for Perl [ In reply to ]
??????? Original Message ???????

On Monday, June 14th, 2021 at 1:53 AM, Nicholas Clark <nick@ccl4.org> wrote:

> On Sat, Jun 12, 2021 at 07:12:51AM +0000, Nicholas Clark wrote:
> > Thank you for wasting my time.

> My statement here was inappropriate. It's not a good example from anyone,
> let alone someone supposed to be showing leadership. Brett replied privately
> to me, politely and without any sarcasm or other failings that I made in
> public. I commend him on keeping a cooler head under pressure than I do.
> Everyone makes mistakes. (Clearly I just demonstrated this)
> I don't want people to think that mistakes, unpopular opinions, or anything
> else is not tolerated, and hence be afraid to contribute. That would be the
> death of discussion, and the resulting groupthink would be ultimately kill
> Perl.

Thank you. I must admit, my reply to you was not quite devoid of sarcasm. You're
welcome to share it. I appreciate the noble characterization, though.

> However there are four or five individuals who seem to have more confidence
> in their opinions than their reasoning should warrant, and often generate a
> large amount of list traffic with a lower density of useful input. These
> messages take considerable time and patience to meaningfully respond to. At
> times, about 1% of the subscriber base can generate 10% of the list volume,
> which spreads the actionable content very thin. That this keeps happening
> gets extremely frustrating.

This is a "well know" phenomenon. It's related to the 80/20 rule. Not sure what
to suggest be done about it.

https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture)

Anyway, thank you for the email. No harm no foul. I am quite excited about the
RFC program and want to see it get firmly established. Thanks for all you do.

Cheers,
Brett

> To be clear - I'm not saying that anyone's contribution is worthless. Far
> from it - I know that several individuals who at times frustrate myself and
> others have also had useful insights that no-one else has had, or reported
> bugs where the reaction was "oops, that's not good, we had better fix that
> quickly". When names are mentioned in private conversations, I make sure
> that I defend their virtues too, and am clear that I don't want to cut
> anyone out.
>
> It feels that to be on the PSC you're expected to have the patience of a
> saint, the wisdom of Solomon, ... a bunch more clichés ... infinite time and
> infinite stamina. Whereas, like Soylent Green, the PSC is made of people.
>
> Just 3 people. It's like we're three bartenders in a large rowdy bar, trying
> to maintain the atmosphere and keep everyone happy, where it always seems
> like it's on the cusp of a fist fight breaking out. If that's your unpaid
> side hustle 7 days a week, it can get draining.
>> Humans can't live up to these expectations, and eventually their patience
> frays.
>
> On balance, I still believe that I am net force for good, and anyone reading
> the list archives would reach the same conclusion.
>
> Nicholas Clark