News: 0000828384

For those who are wondering about the state of the proposed Perl 7 fork and the role of the newly formed Perl Steering Committee, Ricardo Signes has put together a detailed explanation that is worth a read. " You should not expect to see a stream of unjustified dictates issuing forth from some secret body on high. You should expect to see perl5-porters operating as it generally did: with proposals coming to the list, getting discussion, and then being thumbed up or down by the project manager. This is what has been happening for years, already. Some proposals were already discussed by the project manager and some were not. If you eliminated any named mailing list for doing this, it would still happen. The PSC is a means to say that there is a default group for such discussions. If you were wondering, its initial membership was formed from 'the people who came to or were invited to the Perl Core Summit' over the last few years. "

From :

Ricardo Signes <perl.p5p-AT-rjbs.manxome.org>

To :

perl5-porters-AT-perl.org

Subject :

Q: what the hell is going on? // A: ...

Date :

Wed, 5 Aug 2020 16:46:31 -0400

Message-ID :

<20200805204631.GA6591@debian>

Fellow list members,

I have gotten a lot of messages in the form "what the hell is going on?" and

it's one of those phrases that people use to mean a lot of different things,

and the way its delivered can bring a lot of different expectations to the

forefront. I think it's a really good question for perl5-porters to have

answered. If we're going to have a lot of disagreement, I want to make sure we

all know what we're disagreeing about!

I am trying very hard not to just swoop in at the tail end and throw another

opinion on the fire.¹ I have send a draft of this email to Sawyer and the Perl

Steering Committee to make sure I'm not standing apart from the rest of that

group but saying I can speak for them. That means that I am trying to

elaborate the "what the hell is going on" from the perspective of the PSC, but

I'm going to be pretty liberal about throwing in my personal perspective here.

Okay, here we go.

## ONE: TO BREAK OR NOT TO BREAK

The big idea actually being debated is, I think, about this paragraph in

perlpolicy:

Requiring end-user programmers to change just a few language constructs,

even language constructs which no well-educated developer would ever

intentionally use is tantamount to saying "you should not upgrade to a

new release of Perl unless you have 100% test coverage and can do a full

manual audit of your codebase." If we were to have tools capable of

reliably upgrading Perl source code from one version of Perl to another,

this concern could be significantly mitigated.

This paragraph and ones like it form a policy that each new release of Perl may

add, but may almost never take away, behaviors. It also enshrines certain bugs

as canon. Mark Jason Dominus once wrote in parody, "Sure, it would be nice if

2+2 had been made to evaluate to 4 and not 5, but the ship has sailed on that

front." We're not there, but sometimes it feels like it. Every mistake made

before and made now walls perl into a smaller possible set of futures, with

very little recourse to break free.

The central Perl 7 question is not about version numbering, but rather about

backward compatibility guarantees. (There is another key question we need to

grapple with, in the current turmoil, and I'll come back to it. It is the

question of governance -- but that is *also* a question of perlpolicy.)

Sawyer's position is that Perl 5 is too constrained by backward compatibility

to grow significantly in utility or rate of use, at this point. There are a

few possible responses to that, including at least:

* I agree, let's figure out which constraints can, like chains, be shrugged

off so we can move ahead.

* I agree with this premise. Therefore, we should let Perl continue along

its current course, becoming ever more stable as it is used by an

ever-diminishing audience until it is given its rightful place in the Hall

of the Honored Dead.

* I reject this premise. There is a lot of room for forward motion without

breaking changes, if we would just stop trying to change the rules and move

forward.

I think there is merit to all of these positions.

Maybe there are kinds of backward compatibility that can be shrugged off

without disrupting the vast majority of Perl users, while making the language

easier to use and (very importantly) easy to *continue* to improve. This is

obviously the core hope of the Perl 7 plan.

Maybe even the best-chosen set of improvements will be terrific for a small

audience of Perl users, who will be able to avoid or easily adapt to

disruption and then gain ground from the changes -- but the great majority of

the changes will be painful, Perl use will rapidly fall off, and we won't win

any new users.

Maybe we can keep on the current course, finding ever-smaller niches in which

to fit new syntax and features, making life better for users of cutting-edge

Perl, and focusing on breaking compatibility is a symptom of fatigue, not

technical fact.

**The first thing people need to decide is probably what they think on this

question.** Here's what I think: there is room for forward motion without

breaking changes, but it's painstaking and tedious. It gets worse over time.

We aren't picking up new core developers for a bunch of reasons, but one is

"it's just too much of a slog to -do- anything." So I am in favor of making

selective breakages in order to make the language better and the implementation

more workable. I think this is the core of the Perl 7 plan, and the big

question is "what are those selective breakages."

## TWO: HOW SHALL I BREAK THEE?

A lot of people disagree with the premises that lead to "okay, let's break some

backcompat," and that needs one kind of discussion. Other people agree with

the premises and conclusion, but then don't agree on the specifics of what is

"safe to break."

I think it's important to just say very clearly: There is not yet a consensus

here, seemingly among any two people. There is not a cabal of people saying

"let's all break these five things we agree on, quick, before anybody can stop

us." I think sometimes it smells that way, but I have been in the discussions

about what we can and should change, and why, and there is no unified front.

The big agreement is, if anything, "Changing the version numbering to make it

clear when to expect breaking changes is reasonable."

There are a lot of specific changes being discussed. Everyone on the PSC seems

to agree on Perl 7.0.0 existing at some point in the next twelve months.

Beyond that, it's up in the air. The next most common discussion is "and we

change the set of features enabled by default."

There is also a lot of discussion about how to test this, what might break, and

so on. I know that not everybody will agree on whether there can ever be

enough testing, but the impact on existing code is a big question to be

answered. Nobody is arguing that will attract a new set of users and

developers by first alienating all the existing ones. The question is, can we

reduce the impact to only those people who are very unlikely to be affected by

the change anyway? (Answer: I don't have an answer yet.)

So, what *is* the specific plan? The plan is to come up with a plan. I have

heard suggestions that I like and suggestions that I don't like. I will hold

off on holding forth, just now, on what I like best. Instead, I want to talk

about how a plan gets come up with.

## THREE: WHY WERE THE FORMER DAYS BETTER THAN THESE?

Once upon a time, Larry presided over p5p and made decisions about what the

language would do, and this was mostly great because Larry was great, and even

when it wasn't great, we got an answer and we knew it was final.

Then Larry went and worked on another project and we got a string of other

project managers who also made decisions and whether or not this was great is

something to be debated by programming language historians someday.²

The decisions of those project managers was also final, but it rarely seemed

like it led to major strife, for a bunch of reasons. One of these was that

changes got workshopped off the list before being presented. When posted, many

key contributors had already had an argument elsewhere and could now

immediately say, "Yes, I can get behind this." This was not how all changes

worked, and I don't think it's even how *most* worked, but it was extremely

useful for contentious changes.

There was sometimes discussion of how we (where "we" was "the committers" or

"the members of fiveperl") might vote on matters, but I don't think ever took a

vote. (I may be mistaken.) Instead, the project manager managed by the

consent of the managed, established by pre-vetting some ideas and deeply

engaging with others publicly, and often doing both.

This process happened for "let's do Perl 7", but I think that somewhere along

the way, it fell apart. It seemed like consensus had been reached, but it had

not, and when an announcement was made, the expected "Yes, I can get behind

this"es did not all materialize. This meant that there was confusion in the

public discussion, obvious dissent among ranks that were usually closed, and

having a public discussion was going to be very, very difficult without first

establishing some consensus among a core group.

## FOUR: FIVEPERL AND THE PERL STEERING COMMITTEE

Lots of the pre-gathering of consensus back in the day happened on a private

mailing list called fiveperl. The membership was mostly the committers to

perl5.git, but not exactly. For example, as we added committers whose were

really meant only to make releases, they didn't get added to fiveperl. Also,

editing the membership of fiveperl meant dealing with humans who would have to

manually update configuration, which they always did, but it wasn't trivial, so

other committers never got added because it was a pain. The system wasn't

perfect.

Because fiveperl's membership became less reflective of reality, it wasn't how

discussion about the future of Perl happened. As I said above, what happened

instead turned out to be kind of a mess. In light of that mess, there was a

realization that this really needed to be fixed: we needed to establish a group

that served this function of discussion of what's going on without an unbounded

number of voices.

I believe that one of the most important things about fiveperl is that it was

not a decision-making body. It was a cabinet chamber in which the project

manager could speak privately with people who could say what they thought

without worrying too much about how their words would be construed by the whole

body of people interested in Perl. Someone could tell me, "Rik, you are just

tired, this is a bad idea, go to sleep and re-read your post in the

morning" and it would be fine, because it was a private conversation.

We're now grapping with a question of governance: Sawyer said, "Here's what

is going to happen" and a bunch of people said, "Can he even *do* that?" I

believe the answer is "yes," but I agree that it's not entirely clear. Or,

more specifically: if Sawyer governs the project through the consent of the

governed, how are the governed represented? That means:

1. Who are the representatives?

2. How are they empowered to act?

This question is not settled. There now exists "the Perl Steering Committee"

and it has no definite charter or constitution. (There's a page on the wiki³

but it's thrown together.)

Who is going to settle this? To my mind, it's something like the active

committers to the project. This needs clearing up because, for example, does

this include Stevan Little, who has a commit bit because he made a release

once?

And what does it mean to settle this? Part of it is, "We need the charter to

written, sufficient, and something that is not being argued about."

Here's what I can tell you so far:

* We're having irregularly-scheduled teleconferences to talk about what we

can agree on

* The primary function of the PSC (which I imagine as fiveperl v2) is to

provide advice and feedback on ideas to help refine them and form consensus

before they're put up for general discussion

* Almost certainly the only decision that it will be empowered to make will

be the removal of the project manager from office; in all other cases, the

final decision is with the project manager, who has a strong incentive to

see that consensus is established.

You should not expect to see a stream of unjustified dictates issuing forth

from some secret body on high. You should expect to see perl5-porters

operating as it generally did: with proposals coming to the list, getting

discussion, and then being thumbed up or down by the project manager. This is

what has been happening for years, already. Some proposals were already

discussed by the project manager and some were not. If you eliminated any

named mailing list for doing this, it would still happen. The PSC is a means

to say that there is a default group for such discussions. If you were

wondering, its initial membership was formed from "the people who came to or

were invited to the Perl Core Summit" over the last few years.

Finally, I want to express my very strong personal feeling that these kind of

preliminary discussions can't be effective if they are completely recorded.

The addition of an audience is a hindrance to free and open communication among

trusted peers. This is not a seizure of power if the body in question has no

decision-making authority that is not already vested in the project manager.

FIVE: RJBS IS FINALLY WRAPPING UP

To my mind what needs to happen is this:

1. We need to firm up the "here is what the PSC is and is not" document,

post it, and agree that it's done. Either that leads to people rejecting

the validity of future decisions or not, but we can't live in a constant

state of constitutional crisis.

2. We need to begin producing a clear set of intended changes, like "this is

the set of default features we want to test for impact on CPAN", discuss

those on perl5-porters, and take action on them. We need specific

avenues we're exploring or planning on, rather than a state of infinite

uncertainty.

Right now #1 and #2 are, in a sense, happening simultaneously. This is

painful, because it feels like we're getting proposed courses of action from a

body with no clear rules for existing and no clear set of powers, where that

set of powers may or may not be infinite and may or may not be legitimately

claimed. That question needs to be put to rest.

I don't think we can usefully discuss specific plans while we're still

concerned about the authority from which decisions flow, and I think we're

close to presenting an answer to how that works, which each of us on

perl5-porters (and beyond) will need to individually accept or reject as valid.

Until that happens, I just hope for a little period of calm and good faith.

--

rjbs

[1] MADISON: I've been fighting for Perl 5 alone, where have you been?

RJBS : … France.

[2] The ACM's History of Programming Languages conference, held only fifteen

years or so, was meant to happen this year but was postponed. Perhaps Perl

5 can make it into the next conference's agenda.

[3] https://github.com/Perl/perl5/wiki/Perl-Steering-Committee