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

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

Thread Previous
From:
Philip R Brenan
Date:
August 5, 2020 21:01
Subject:
Re: Q: what the hell is going on? // A: ...
Message ID:
CALhwFR=_=E1eBc8Yy4=o0xUcd9_W4CbggDZE1A9mExjHBEE6RQ@mail.gmail.com
Please make sure that breaking changes are controlled by pragmata so that
the integrity of CPAN can be preserved.

On Wed, Aug 5, 2020 at 9:46 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

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


-- 
Thanks,

Phil <https://metacpan.org/author/PRBRENAN>

Philip R Brenan <https://metacpan.org/author/PRBRENAN>

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About