develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Pre-RFC: perldelta naming

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
January 10, 2022 13:41
Subject:
Re: Pre-RFC: perldelta naming
Message ID:
CA+vYcVw7YbmTpA41oLQcvtvhfMrS-cd5iOeYA9T-jKkOjgCSMg@mail.gmail.com
On Sat, Jan 8, 2022 at 8:51 AM Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>
> On Fri, Jan 7, 2022, at 3:59 AM, Nicholas Clark wrote:
>
> I'd be interested as to what release managers and folks who regularly apply
> patches think. (Or if anyone wants to try implementing this change and then
> roll a release tarball locally to see how it works)
>
>
> I'm not fussed.  Very occasionally I get confused by this setup, but I'm sure I'd get a little confused by the alternative.  But I think that the second kind of confusion would only affect people who had been poisoned by the current setup. ;-)
>
> In other words:  as a once-frequent releaser, I'm not sure I'd be bothered by the change, and the question is probably "Wait, why did we do this, again?"

I would not worry about release managers because I suspect in every
case ever they have always known the number of the release they are
rolling :-).  I would worry about Jane Programmer who submits the
occasional PR and has to trawl through the pod/ directory to figure
out which delta to update, which will most likely be the wrong one by
the time the PR is merged.  Unless someone is paying very close
attention and takes manual steps to modify the PR before merging, as
often as not a previous perldelta rather than the current one will get
updated.

I believe avoiding such disconnects and lowering the friction a new or
occasional contributor faces provide the answer to "why did we do
this?" and this along with, as Nicholas points out, the fact that
changing would break things that are currently working and would
require effort to get unbroken, make me wary of changing how this
works.  Plus, there were no actual reasons/benefits provided for
making the change other than what we do now involves renaming a file.
Which doesn't seem to be causing any problems I'm aware of.

There was an unrelated suggestion to have an index of all the
perldeltas.  We could resurrect perlchanges.pod and have it be an
automatically-generated index of all the perldeltas, or we could
revamp perlhist so that releases are in descending order and have
links to the perldeltas (where available).  Patches welcome, as we
used to say.

Thread Previous | Thread Next


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