develooper Front page | perl.perl5.porters | Postings from July 2020

PSC Meeting Notes - 2020-07-21

Todd Rinaldo
July 23, 2020 18:41
PSC Meeting Notes - 2020-07-21
Message ID:

The "Perl Steering Committee" (PSC) is a group of folks focused on moving the Perl programming language forward. We are currently meeting via video conference weekly in an attempt to accelerate the process. To be transparent, we take meeting notes and post them to the Perl wiki. We will also be sending them to the perl5-porters mailing list in the future. You can see all previous notes here: <> <>

Date: 2020-07-21 13:00 GMT
Location: Zoom

Sawyer <>
James Keenan <>
Todd Rinaldo <>
H.Merijn Brand <>
Karl Williamson <>
Paul Evans <>
Nicolas R. <>
Stuart Mackintosh <>
John Lightsey <>
Ricardo Signes <>
Dagfinn Ilmari Mannsåker <>
Tony Cook <>
 <>Meeting notes

 <>Meeting objectives / agenda

Governance review - voting process, quorum
Inclusivity of others
Appointment of secretary to manage arrangements, agenda, and minutes
 <>PSC Secretary

Todd nominated as secretary

Responsible for:

preparing the agenda
notifying participants of arrangements
setting up comms
ensuring notes are taken
publishing notes as required
nominating a replacement when unavailable
 <>PSC Community advocate

Paul (LeoNerd) will act as community advocate, to solicit community feedback for Perl Steering Committee (PSC) consideration.

 <>Governance Discussion

We agreed early in the meeting that governance needed to be more settled before we could meaningfully action and determine language design.

An early discussion centered around how we could address people who were not participating on calls for various reasons. The goal of the calls is to condense days of asyncronous exchange into a small period of time. Sawyer expressed that keeping up with with these conversations on complicated topics in asynchronous manner on emails is proving to be unproductive - and at some point - unmanageable.

As long as meeting notes continue to be provided and those not joining have an opportunity to respond, we agreed that this concern was a non-issue. Some language about how many days people should have to respond before a decision moves forward needs to be crafted into governance.

Another concern was raised about how we could be inclusive of people outside of PSC. PSC members are all able to and if possible should seek input from people in the wider Perl Community. We reaffirmed the value of getting input from anyone, whether attending the meetings or not. Paul Evans was nominated to be an official community advocate and actively seek out concerns and comments from the community so they could be heard and reviewed.

We also discussed how we would address dual life authors who are unwilling to accommodate changes to the language over time. If these modules choose to bump their version over what the latest Perl ships, they can cause wide-spread breakage. This is already a risk and has not yet been something that needs to be addressed.

Jim Keenan raised a concern that a critical mass existed for meeting attendance where the meeting became unproductive. We briefly discussed finding ways to break away issues from the group for detailed discussion. The sub-group could then come back with findings.

Voting balance was discussed. Not all votes by PSC members are equal votes on all issues. There are Subject Matter Experts (SMEs) who should be able to object to an idea in a particular area and potentially kill it. Tux inquired about the effect of not voting <>. Rust has sub-groups in different areas of the language: compiler, etc. Debian has Further Discussion as an explicit voting option. JD suggested that different decisions need different governance. Some are of substance, others trivial.

At the end we agreed a best next step might be to produce a governance draft we could use as a basis to discuss this further. Notes from the first meeting produced this draft terms of reference <>. The governance section will be further developed at the next meeting.

 <>Respectfully disagreeing

There were concerns about some of the language in the current PSC draft terms of reference <> implies that joining the committee means you cannot disagree with it.

Sawyer had expressed the importance of genuinely disagreeing and challenging proposals, decisions, and positions. There is nothing objectionable by also expressing personal opinion that disagrees with a proposal, change, or position.

Having said this, we find it important for the PSC to disagree respectfully. This is how we challenge each other to achieve the best outcome for something we care about. If you have a point to make, you should use the established channels or contact the PSC community advocate.

This allows the group to address it in the most effective way, working together as a core group instead of forming public factions.

Participating in the PSC does not mean you have to agree.
You might find the following guidelines on how to respectfully disagree with others useful: <> <> <>
 <>Technical session

After the main call, a few folks interested in discussing the Devel::PPPort / XS issues with Perl 7 <,-XS-and-Devel::PPPort> stayed back to discuss the current proposal. Paul proposed an alternate solution to keep the legacy PERL_REVISION variables by lieing about the version unless someone set #define I_REALLY_KNOW_HOW_TO_USE_PERL_REVISION, but as we re-wrote the plan to incorporate his ideas, the group expressed concern that the alternate plan would require tribal knowledge and introduce long term technical debt. The plan as it stands emits compiler warnings if the legacy variables are used and then can give guidance on the use of the new macros which we believe will be what 99% of XS code wants anyway. Tony and Paul were still not ok with this plan so Todd offered to follow up with them offline and understand their concerns in more detail.

JD pointed out that both Ruby and Python had an interesting interface <> for their version that we might want to consider long term. We also discussed the problem that too many files needed to change in order to bump the version of Perl. Perhaps we could address this in the long term.

 <>Action items from this meeting.

Working group to work on a re-factor of the governance section of the PSC terms of reference for group review
Stuart is going to produce a first draft
We want to meet an hour earlier next week and only discuss governance
This is an optional session.
Devel::PPPort working group ongoing progress.
 <>Next meeting

The next meeting will be Next Tuesday July 28 2020 at 13:00 GMT. The governance discussion will happen at 12:00 GMT for those who want to participate.

 <>Proposed agenda / backlog

A brief report from the governance working group
Working group report on Devel::PPPort / XS for Perl 7.
Defaults Working group report
Does anyone have numbers on how the working list of defaults held up to CPAN testing?
Unicode strings results (karl really thinks this should be a default in Perl 7)
How to disable things and return to v5 defaults when needed. - Feature downgrading
use p5
use compat::perl5 (alternative name to "p5")
use v5 (magical v5.0.0 bundle in perl 7?)
Perhaps we should overload use v with less things not more.
discuss the v7 feature bundle
Assuming a short major life cycle, should there be a 7.2 bundle or just a 7 bundle?
how does one do use v8 in perl 7? Many don't like v8.
Essentially turns on all feature guards which are planned for 8.
Gives people a preview mode for 8 so they can test.
Configure option when building perl?
Environment variable?
use cool::stuff?
-e / -E discussion
Should -E default to v7? v8?
Most people think -e default to v5 and much code has built up around this.
perl -$letter is in short supply.
A reminder: /usr/bin/perl7 doesn't have to be the same thing as /usr/bin/perl5
refactor plans for perlpolicy Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About