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

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

Thread Next
Ricardo Signes
August 5, 2020 20:46
Q: what the hell is going on? // A: ...
Message ID:
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.


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

> 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

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


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.


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.


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

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

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.


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

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.


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


Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About