PSC #037 - 2021-09-10
Present: Paul, Rik, Neil
Also present by invitation: Nick (initially)
We invited Nick along to talk about the RFC process and how best to
keep things moving. Before we got onto that he added some thoughts
about the taint plan, pointing out that we can't do a `taintperl` in a
similar style to `suidperl` of old, because of XS modules and so on. It
has to be a real compile-time `Configure` option.
We moved on to the main RFC process chat with Nick. It seems that the
process of who does what is still a bit unclear currently. Does PSC
need a regular agenda item to scan over the "current in-flight" and see
what might happen next? The current RFC process defines a state machine
with states, but no defined triggers for transitions. We need to define
what causes these state changes. The current plan is to create a google
sheet of "pending (Pre-?)RFCs", to use as a regular agenda item for the
PSC to discuss; either every week or every two weeks. It ought to
remain a fairly short list with not much action needed so hopefully it
won't take much time. Neil will create the initial version, and
thereafter PSC can maintain it each time.
Then Nick left and we returned to our regular meeting.
Regarding eventually getting rid of the `Internals::getcwd()` function,
we observed that `dist/PathTools/Cwd.pm` currently uses it, but nothing
else on CPAN appears to. This should be an easy candidate to get moved
into a new builtins-namespace; possibly by also adding a deprecation
warning to the existing function.
To continue the SvUTF8 flag discussion: We agree we should rename the
flag. In some ways it feels similar to the `G_ARRAY` -> `G_LIST` rename
- it's not really fixing any fundamental bug or issue, it's just
picking a better name that more accurately reflects what the thing is,
which may help user understanding and so indirectly help avoid bugs.
The problem here is that there's no obvious candidate for what the
better name is, unlike with `G_LIST`. Paul and Rik will discuss
thoughts of a better name and then suggest it with a simple "yes/no"
vote on the list. If the list overall agrees we shall rename it.
We looked at what next actions should take place to continue moving the
namespaces issue forward. Paul will write a pre-RFC message to open the
RFC process on this one. Initial candidates for function suggestions
there would be `getcwd()` (see above) and `trimmed()` (see various p5p
threads and github comments).
Quirks: no time this week due to all of the above. Neil and Rik can
have fun with that one next week as I will be on holiday. ;)
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Present: Paul, Rik, Neil
Also present by invitation: Nick (initially)
We invited Nick along to talk about the RFC process and how best to
keep things moving. Before we got onto that he added some thoughts
about the taint plan, pointing out that we can't do a `taintperl` in a
similar style to `suidperl` of old, because of XS modules and so on. It
has to be a real compile-time `Configure` option.
We moved on to the main RFC process chat with Nick. It seems that the
process of who does what is still a bit unclear currently. Does PSC
need a regular agenda item to scan over the "current in-flight" and see
what might happen next? The current RFC process defines a state machine
with states, but no defined triggers for transitions. We need to define
what causes these state changes. The current plan is to create a google
sheet of "pending (Pre-?)RFCs", to use as a regular agenda item for the
PSC to discuss; either every week or every two weeks. It ought to
remain a fairly short list with not much action needed so hopefully it
won't take much time. Neil will create the initial version, and
thereafter PSC can maintain it each time.
Then Nick left and we returned to our regular meeting.
Regarding eventually getting rid of the `Internals::getcwd()` function,
we observed that `dist/PathTools/Cwd.pm` currently uses it, but nothing
else on CPAN appears to. This should be an easy candidate to get moved
into a new builtins-namespace; possibly by also adding a deprecation
warning to the existing function.
To continue the SvUTF8 flag discussion: We agree we should rename the
flag. In some ways it feels similar to the `G_ARRAY` -> `G_LIST` rename
- it's not really fixing any fundamental bug or issue, it's just
picking a better name that more accurately reflects what the thing is,
which may help user understanding and so indirectly help avoid bugs.
The problem here is that there's no obvious candidate for what the
better name is, unlike with `G_LIST`. Paul and Rik will discuss
thoughts of a better name and then suggest it with a simple "yes/no"
vote on the list. If the list overall agrees we shall rename it.
We looked at what next actions should take place to continue moving the
namespaces issue forward. Paul will write a pre-RFC message to open the
RFC process on this one. Initial candidates for function suggestions
there would be `getcwd()` (see above) and `trimmed()` (see various p5p
threads and github comments).
Quirks: no time this week due to all of the above. Neil and Rik can
have fun with that one next week as I will be on holiday. ;)
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/