Skip to content

SC Notes 2020 07 21

Jump to bottom
Todd Rinaldo edited this page Jul 23, 2020 · 3 revisions

Perl Steering Committee (PSC) Meeting

Arrangements

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

Attendees

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 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

https://metacpan.org/release/perl

Clone this wiki locally