Front page | perl.perl5.porters |
Postings from June 2021
Re: Creating an RFC process for Perl
From: Nicholas Clark
June 9, 2021 07:57
Re: Creating an RFC process for Perl
Message ID: 20210609075731.GT16703@etla.org
On Tue, Jun 08, 2021 at 08:24:53PM +0200, Branislav Zahradník wrote:
> Generally good Idea
> I'd suggest structure:
> including different languages
> 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,
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
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.