Mailing List Archive: bring out yer perldeltas!

bring out yer perldeltas!

Nov 15, 2017, 12:12 PM

Post #1 of 8 (414 views)

Please consider adding perldelta entries for any work committed during
the last month in the next couple of days: Perl 5.27.6 is due to be
released on Monday (November 20).

And a reminder regarding a recent decision made on perldelta updates,
courtesy
of Karl Williamson:

> At the core hackathon [last month], we took some steps to address this...
>
> It is now the committer's responsibility to make sure there is a
perldelta entry for the commit. This may entail going back to the author
to get one. For a merge commit, the final commit before the merge should
be a perldelta entry.
>
> Not all commits need a perldelta entry. We decided that the commit
message should be decorated with a brief indication as to the committer's
view on this when no perldelta change is included.
>
> There wasn't a decision as to the exact nature of this decoration. I am
hereby proposing that it should be
>
> NPD
>
> on a line by itself at or very near the bottom of the commit message (No
Perl Delta). At negligible overhead, this should lessen the number of
instances where the RM has to worry about missing entries.

thank you!
your friendly newbie porter,
Karen Etheridge
ether@cpan.org

Re: bring out yer perldeltas! [ In reply to ]

public at khwilliamson

Nov 15, 2017, 12:46 PM

Post #2 of 8 (414 views)

Permalink

On 11/15/2017 01:12 PM, Karen Etheridge wrote:
> Please consider adding perldelta entries for any work committed during
> the last month in the next couple of days: Perl 5.27.6 is due to be
> released on Monday (November 20).
>
> And a reminder regarding a recent decision made on perldelta updates,
> courtesy
> of Karl Williamson:

Actually there was some dispute as to whether we really agreed to this
or not, so I haven't been doing it myself.
>
> > At the core hackathon [last month], we took some steps to address this...
> >
> > It is now the committer's responsibility to make sure there is a
> perldelta entry for the commit. This may entail going back to the
> author to get one. For a merge commit, the final commit before the
> merge should be a perldelta entry.
> >
> > Not all commits need a perldelta entry. We decided that the commit
> message should be decorated with a brief indication as to the
> committer's view on this when no perldelta change is included.
> >
> > There wasn't a decision as to the exact nature of this decoration. I
> am hereby proposing that it should be
> >
> > NPD
> >
> > on a line by itself at or very near the bottom of the commit message
> (No Perl Delta). At negligible overhead, this should lessen the number
> of instances where the RM has to worry about missing entries.
>
> thank you!
> your friendly newbie porter,
> Karen Etheridge
> ether@cpan.org <mailto:ether@cpan.org>

Re: bring out yer perldeltas! [ In reply to ]

xsawyerx at gmail

Nov 15, 2017, 12:50 PM

Post #3 of 8 (414 views)

Permalink

To be clear: Documenting the commit is up to core member who either
wrote the patch or applied the patch.

* If you applied someone's patch, please document it in perldelta if
it's necessary.
* If you wrote a patch, please document your change in perldelta if it's
necessary.
* If you wrote any patches or applied any code, please do a once-over to
make sure you documented the important ones.
* When in doubt, ask! :)

We shouldn't have such stray commits.

When it comes to how to document a commit *was* document or not, we'll
sort that out regardless of 5.27.6. For now, let's just help Ether with
this.

On 11/15/2017 09:12 PM, Karen Etheridge wrote:
> Please consider adding perldelta entries for any work committed during
> the last month in the next couple of days: Perl 5.27.6 is due to be
> released on Monday (November 20).
>
> And a reminder regarding a recent decision made on perldelta updates,
> courtesy
> of Karl Williamson:
>
> > At the core hackathon [last month], we took some steps to address
> this...
> >
> > It is now the committer's responsibility to make sure there is a
> perldelta entry for the commit. This may entail going back to the
> author to get one. For a merge commit, the final commit before the
> merge should be a perldelta entry.
> >
> > Not all commits need a perldelta entry. We decided that the commit
> message should be decorated with a brief indication as to the
> committer's view on this when no perldelta change is included.
> >
> > There wasn't a decision as to the exact nature of this decoration.
> I am hereby proposing that it should be
> >
> > NPD
> >
> > on a line by itself at or very near the bottom of the commit message
> (No Perl Delta). At negligible overhead, this should lessen the
> number of instances where the RM has to worry about missing entries.
>
> thank you!
> your friendly newbie porter,
> Karen Etheridge
> ether@cpan.org <mailto:ether@cpan.org>

Re: bring out yer perldeltas! [ In reply to ]

perl at froods

Nov 15, 2017, 3:06 PM

Post #4 of 8 (414 views)

Permalink

Thanks Sawyer!

One more thing -- when adding documentation in a separate commit than the
code changes, especially if some time has passed between the two, it is
helpful to also mention in the commit message which commit(s) the
documentation relates to: e.g. "perldelta for changes to frobnitz headers
(commits deadbeef..cafebabe, acedfeed)". thanks again!

On Wed, Nov 15, 2017 at 12:50 PM, Sawyer X <xsawyerx@gmail.com> wrote:

> To be clear: Documenting the commit is up to core member who either
> wrote the patch or applied the patch.
>
> * If you applied someone's patch, please document it in perldelta if
> it's necessary.
> * If you wrote a patch, please document your change in perldelta if it's
> necessary.
> * If you wrote any patches or applied any code, please do a once-over to
> make sure you documented the important ones.
> * When in doubt, ask! :)
>
> We shouldn't have such stray commits.
>
> When it comes to how to document a commit *was* document or not, we'll
> sort that out regardless of 5.27.6. For now, let's just help Ether with
> this.
>
> On 11/15/2017 09:12 PM, Karen Etheridge wrote:
> > Please consider adding perldelta entries for any work committed during
> > the last month in the next couple of days: Perl 5.27.6 is due to be
> > released on Monday (November 20).
> >
> > And a reminder regarding a recent decision made on perldelta updates,
> > courtesy
> > of Karl Williamson:
> >
> > > At the core hackathon [last month], we took some steps to address
> > this...
> > >
> > > It is now the committer's responsibility to make sure there is a
> > perldelta entry for the commit. This may entail going back to the
> > author to get one. For a merge commit, the final commit before the
> > merge should be a perldelta entry.
> > >
> > > Not all commits need a perldelta entry. We decided that the commit
> > message should be decorated with a brief indication as to the
> > committer's view on this when no perldelta change is included.
> > >
> > > There wasn't a decision as to the exact nature of this decoration.
> > I am hereby proposing that it should be
> > >
> > > NPD
> > >
> > > on a line by itself at or very near the bottom of the commit message
> > (No Perl Delta). At negligible overhead, this should lessen the
> > number of instances where the RM has to worry about missing entries.
> >
> > thank you!
> > your friendly newbie porter,
> > Karen Etheridge
> > ether@cpan.org <mailto:ether@cpan.org>
>

Re: bring out yer perldeltas! [ In reply to ]

sprout at cpan

Nov 16, 2017, 12:31 PM

Post #5 of 8 (408 views)

Permalink

Sawyer X wrote:
> * If you wrote a patch, please document your change in perldelta if it's
> necessary.

I believe I have done so for all my significant commits.

Re: Bring out yer perldeltas! [ In reply to ]

perl.p5p at rjbs

Aug 13, 2021, 3:33 PM

Post #6 of 8 (363 views)

Permalink

On Fri, Aug 13, 2021, at 4:16 PM, Karen Etheridge wrote:
> Here are the number of commits, by author, since the release of v5.32.3. So far, there has been one (1!!!) commit to pod/perldelta.pod (and it was one that didn't need to be done, since the list of updates of dual-life modules are autogenerated at release time). That means that there are a lot of perldelta updates still to come in advance of next week's release of v5.35.4.

Thanks for the nudge! I believe I only made one delta-worthy change (removing "switch" from the v5.36 bundle) and I have updated the delta accordingly.

--
rjbs

Re: Bring out yer perldeltas! [ In reply to ]

perl5 at tux

Aug 16, 2021, 6:47 AM

Post #7 of 8 (363 views)

Permalink

On Fri, 13 Aug 2021 13:16:28 -0700, Karen Etheridge <karen@froods.org>
wrote:

> Here are the number of commits, by author, since the release of
> v5.32.3. So far, there has been one (1!!!) commit to
> pod/perldelta.pod (and it was one that didn't need to be done, since
> the list of updates of dual-life modules are autogenerated at release
> time). That means that there are a lot of perldelta updates still to
> come in advance of next week's release of v5.35.4.
>
> thank you for your kind attention.
>
> 1 H. Merijn Brand <perl5@tux.freedom.nl>

My commit was merely a re-order of previous commits and a few
corrections. I don't feel like being able to write the reasoning for
the original patch(es)

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org

Re: Bring out yer perldeltas! [ In reply to ]

nick at ccl4

Aug 18, 2021, 12:38 PM

Post #8 of 8 (361 views)

Permalink

On Fri, Aug 13, 2021 at 01:16:28PM -0700, Karen Etheridge wrote:
> Here are the number of commits, by author, since the release of v5.32.3. So
> far, there has been one (1!!!) commit to pod/perldelta.pod (and it was one
> that didn't need to be done, since the list of updates of dual-life modules
> are autogenerated at release time). That means that there are a lot of
> perldelta updates still to come in advance of next week's release of
> v5.35.4.
>
> thank you for your kind attention.
>
> 139 Karl Williamson <khw@cpan.org>
> 22 Ricardo Signes <rjbs@semiotic.systems>
> 12 Nicholas Clark <nick@ccl4.org>

Was I really *that* active that I'm in third place?

Anyway, the only thing that I did that is externally visible is sort.pm,
which I have now documented.

Thank you for cat herding this release.

Nicholas Clark