Mailing List Archive

PSC #022 2021-05-28 minutes
[.These are the minutes from 11 days ago. They are delayed because I didn't
get a chance to draft then until after Neil had gone on holiday, and I
discovered that I needed some clarification from him before I could complete
them.]

Neil, Nick and Rick present.

`use warnings` as part of `use v5.36`

Consensus was that there wasn't anything still to discuss, and we should try
this. Rik has already mailed p5p with this.

`use sort`

Attempting to summarise this, I realise that this belongs in its own mail.

Vulnerabilities in cpan/ modules

https://github.com/Perl/perl5/pull/18613 had got missed. We reviewed it, and
it is now merged.

The changing of the PSC guard

As the end of the PSC term is approaching, we considered how we should
review it, learn from it and seek to evolve/do better.

We think that having 3 people is good, as is sending meeting notes to p5p,
and rotating the agenda duties. Having 3 people with a balance of skills is
useful. We figured that currently we have

- Deep knowledge of the perl internals
- Deep knowledge of the perl language, p5p, releasing and processes
- Broad knowledge of the perl communities, Toolchain and our downstream

We need a balance of skills, and we don't need everyone to be able to do
every task, but it is important that the individuals on the committee can
work well together. What would be the best makeup?

3 Nicks would not make a good committee
3 Neils definitely not
3 Riks maybe

But this balance is outside of anyone's control as the committee is
appointed from the top 3 individual candidates as ordered by voting in the
election. We're not suggesting changing the rules - we're observing that
ensuring a fair, transparent and representative system to appoint a PSC then
relies on the candidates' quality and adaptability to also have that PSC be
maximally effective.

"What didn't work so well" is somewhere between "we're not so sure" and
"events" - external surprises that need attention, and feel like running
hard to stand still.

(Various versions of quotes involving "events" are attributed to several
politicians - the gist of all is basically the same.)

We're soliciting feedback p5p, and welcome it to be sent either to
steering-council@perl.org, or back to the list. This would be input to the
incoming PSC.

Communications outside p5p

There wasn't an official announcement for v5.34.0 (posted externally). By
the time we get to 7, we should be making more of a fanfare. Things like a
blog post to blogs.perl.org on v5.34.0, but also post to dev.to to reach
outside the echo chamber, ensure that we have coverage on LWN.net, etc.

We should do this (both "inside" and "outside"), but we'd love to delegate
this. "Events" have already overtaken these minutes - Yuki Kimoto has kindly
volunteered to do this for v5.34.0, and we'll see how to build from this.

personal development branches/forks of perl5.git

Historically folks have pushed their personal development branches into the
main repository. This was the only way with perforce, and still made sense
when we were hosting our own git instance.

However GitHub changes two things
- It is trivial to host your "own" repository with your own branches
- It is common to "fork" (ie copy) the main repository, which then gets all
branches

The upshot of this is that, even if individuals are diligent and delete
their ephemeral branches from the main repository once they are no longer
needed, folks who clone it will get these ephemeral branches forever.

Pull requests can be made from personal repositories. Right now "smoke-me"
branches need to be in the main repository to function - Rik will
investigate putting "smoke-me" into a different repository.

The aim would be that feature branches would be in one's own fork ie -
rjbs/foo isn't in perl5, but in rjbs.

(once we are comfortable that new active branches aren't in the main
repository, then we can work to resolve the fate of all the existing
branches)

C99

To use C99 features we must bump our minimum requirement to MSVC 2013+ We
will check what the direct implications of this are, before formally
proposing this.

RFCs

Nick has worked further on a "Minimum Viable Process" for RFCs that extends
Neil's earlier plan. The third iteration minimises forward references,
partial duplication and digression, and should read more cleanly. We're
close to having a proposal for how to take feature requests for changes to
the language from "ideas" to something actionable, and are keen to see if it
will fly.

The PSC does not claim a monopoly on enthusiasm

Also in the context of the upcoming Term Elections, we noted that the PSC
does not claim a monopoly on the ability to do things. If you have an idea
of what could be better, you don't need to be *on* the PSC to do it, or even
have someone on the PSC do it for you.

If you find that some source files are defective, and hence want the
official hat for "finding appropriate Lord of the Rings Quotes" (or
somesuch) then if it's not actively counterproductive the PSC will be happy
to declare that they have delegated this hat to you, and are encouraging you
to make recommendations to them/propose PRs for others to review. On
condition that you return the hat if you find you no longer need it.

There's more than enough useful work to go around - the PSC is about
ensuring that important tasks don't fall on the floor, not about claiming
credit for getting things done, and wears far too many hats already. If your
head has space for one of the PSC's implicit hats, we'd love you to wear it.