Need protocol for 'out-of-Objective-band' commits + specific example

[jkeenan]

General Problem: Need Protocol for Commits to alpha Outside of Objectives

Ideally, alpha should be a continuous line of development from v5.32.0, unaffected by whatever is happening in blead (by any definition of 'blead' in any repository).

However, in practice, there may be problems in Perl 5 blead which predate v5.32.0 and which have an adverse impact on our ability to get GREEN results during "outside" testing.

If these problems are corrected in Perl 5 blead, we may wish to "cherry-pick" the fixes into alpha. But we should do so very judiciously, as there is always a lot of churn in Perl 5 blead, especially now.

If we decide we need to perform such a fix, we need to decide where a commit embodying such a fix stands in relation to the roadmap of Objectives we've laid out. Do we:

• Include it at the very end of one 'alpha-dev' branch, re-tag that branch, and re-send it for outside testing?
• Commit it directly to 'alpha' after one dev branch has been committed but before the next dev branch has been cut?
• As the very first commit in a new dev branch?

All 3 options have pluses and minuses.

Case in Point

Our current working branch is alpha-dev-01-bump-version. It has been tagged twice for readiness for outside testing, most recently at tag alpha-01-MC-1. From these tags I have created the smoke-me/jkeenan/dire-wolf in the Perl 5 repository. Smoke-testers have been picking up this branch and testing it as if it were just any other Perl 5 branch.

The only worrisome smoke-testing report we've received is http://perl5.test-smoke.org/report/116073 from champion smoke-tester Carlos Guevara. This report was run on Alpine Linux -- in a way, the VMS of Linuxes -- and specifically with g++-9.3.0 on Alpine Linux. In this run, make failed on every configuration, always before compiling miniperl.

I queried Carlos about this. He called my attention to the fact that he had earlier written p5p about this: https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257532.html. (I should have remembered that, since I asked him to do that.) He reported that the problem had been fixed in Perl 5 blead by this commit:

commit 926c3ce35a7ef910c55cf0964c39718ef5938ca6
Author:     Dagfinn Ilmari Mannsåker <[email protected]>
AuthorDate: Tue Jun 16 13:47:35 2020 +0100
Commit:     Dagfinn Ilmari Mannsåker <[email protected]>
CommitDate: Sat Jul 18 01:28:15 2020 +0100

time64: declare `tm_zone` as `const char*` unconditionally

We only ever assign from `struct tm` to `struct TM`, not the other way
around, so making this const regardless of what `struct tm` has should
be safe.

This commit was made to Perl 5 blead after v5.32.0, so it does not yet appear in our alpha branch or any branch forked therefrom (e.g., smoke-me/jkeenan/dire-wolf).

If we were to "cherry-pick" Ilmari's commit above into the alpha branch at some point, we would hopefully get our perl to build and test on Alpine Linux with g++-9.3.0. We don't have to rush to do this, but it does illustrate the need for us to have a more general discussion of "out-of-Objective-band" commits to alpha.

@atoomic @toddr

Thank you very much.
Jim Keenan