In perl.git, the branch blead has been updated <http://perl5.git.perl.org/perl.git/commitdiff/1b9db2fb33d1c276cb7b213383cbaa41cbfddec1?hp=ff982d0036bfe69b869b03451f0561fa790d4378>
- Log ----------------------------------------------------------------- commit 1b9db2fb33d1c276cb7b213383cbaa41cbfddec1 Merge: ff982d0 402f2e6 Author: Steve Hay <[email protected]> Date: Fri Mar 6 08:22:35 2015 +0000 Merge branch 'maintpolicy' into blead Update our policies w.r.t maintenance releases in the light of discussions had during the release of 5.20.2, in particular: http://www.nntp.perl.org/group/perl.perl5.porters/2014/12/msg224162.html http://www.nntp.perl.org/group/perl.perl5.porters/2014/12/msg224120.html http://www.nntp.perl.org/group/perl.perl5.porters/2015/01/msg224680.html The lists of acceptable/unacceptable changes are essentially unchanged, but the wording now emphasizes that it may not be desirable to cherry-pick every eligible change, and states which types of change are the most important ones to focus on. The intention is to draw up a much shorter list of cherry-pick proposals in the future. Hopefully, a much less daunting list of proposals will reduce the difficulty in getting the required number of votes on the ones that really matter and possibly reduce risk slightly in the process, but not affect how worthwhile the contents of maintenance releases are. commit 402f2e6a64c66cdc2f2f258a7b239ba2f08d51e1 Author: Steve Hay <[email protected]> Date: Thu Feb 26 13:43:43 2015 +0000 maint policy: Note that some changes don't need voting on Again, this is just a statement of the reality that I have experienced in the course of releasing 5.20.1 and 5.20.2. M pod/perlpolicy.pod commit 6788bcfca67cec414c07d12b33aa408248c7bd13 Author: Steve Hay <[email protected]> Date: Thu Feb 26 13:41:43 2015 +0000 maint policy: Note that other voting mechanisms may be used instead of p5p This simply reflects the reality of how 5.20.2's changes were voted on, namely, by the use of the maint-5.20-votes branch. M pod/perlpolicy.pod commit 366d02b54239cc826a2c1ea80fe2117a2869ab39 Author: Steve Hay <[email protected]> Date: Thu Feb 26 13:29:36 2015 +0000 maint policy: Reword/expand the ambiguous "as few changes as possible" phrase This phrase caused much debate during the release of 5.20.2. A literal interpretation of it would be just a version bump, which was clearly not its intention. Debate ensued as to what was its real meaning, and the consensus seemed to be that the list of "acceptable"/"unacceptable" types of change was about right, but that not every eligible change should be included. Not many committers are interested in reviewing a long list of minor spelling corrections etc, causing a lack of interest in voting, and an attendant risk of something important being missed amongst all the "noise". The focus should mainly be on security / crash / regression / installation issues, with the aim being to produce a worthwhile release without needlessly increasing risk and/or burning people out. I hope the new wording captures this. M pod/perlpolicy.pod commit a969a3c5c3f9d9395fbcacd501f00ddda31745b3 Author: Steve Hay <[email protected]> Date: Thu Feb 26 13:20:09 2015 +0000 maint policy: Move paragraph about controversial changes The point was also raised during discussions over whether to include perlunicook.pod in 5.20.2 that exceptions can be made to the rules under the terms of "Rule 2" and the fact that the pumpking is acting on Larry's behalf. However, this is probably best left being implicit, rather than explicitly stating it. Exceptions should be exceptional; we don't want to encourage them! M pod/perlpolicy.pod commit a6f834144147a61af3bf0f2e53c4d9e57518a41d Author: Steve Hay <[email protected]> Date: Thu Feb 26 13:10:50 2015 +0000 maint policy: Minor grammar and style change M pod/perlpolicy.pod commit e2b7b23fd6ea67cbff2215cfdb973af5b9399a3b Author: Steve Hay <[email protected]> Date: Thu Feb 26 13:09:33 2015 +0000 maint policy: Separate build/installation issues from test failures Also clarify a what kind of build/installation "issue" we are referring to. M pod/perlpolicy.pod commit fc088d5fe801176e3cdd0270e996dec703f133ee Author: Steve Hay <[email protected]> Date: Thu Feb 26 13:03:54 2015 +0000 maint policy: Note that old regressions are acceptable too M pod/perlpolicy.pod commit b33e5804c205b3f3febf09a1e4a3eede4523baf4 Author: Steve Hay <[email protected]> Date: Thu Feb 26 09:29:04 2015 +0000 maint policy: Put notes about CPAN modules in one place M pod/perlpolicy.pod commit 79f836023eebc9b5e987eeb183786ff1a6d7334a Author: Steve Hay <[email protected]> Date: Thu Feb 26 09:24:02 2015 +0000 maint policy: No need to keep saying "are [NOT] acceptable" now M pod/perlpolicy.pod commit 64b35da532131e8d41ba5d2692d11748081bf5a9 Author: Steve Hay <[email protected]> Date: Thu Feb 26 09:20:30 2015 +0000 maint policy: Sort acceptable/unacceptable lists into rough priority order This commit makes no changes to any of the wording. M pod/perlpolicy.pod commit c792d632ffa0788feffe59cb0c1ec4acfccea44a Author: Steve Hay <[email protected]> Date: Thu Feb 26 09:17:10 2015 +0000 maint policy: Separate acceptable/unacceptable changes into two litss M pod/perlpolicy.pod ----------------------------------------------------------------------- Summary of changes: pod/perlpolicy.pod | 99 +++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 68 insertions(+), 31 deletions(-) diff --git a/pod/perlpolicy.pod b/pod/perlpolicy.pod index 195ef5d..0bf828c 100644 --- a/pod/perlpolicy.pod +++ b/pod/perlpolicy.pod @@ -250,78 +250,104 @@ no longer ship with Perl, but will continue to be available on CPAN. =head1 MAINTENANCE BRANCHES +New releases of maintenance branches should only contain changes that fall into +one of the "acceptable" categories set out below, but must not contain any +changes that fall into one of the "unacceptable" categories. (For example, a +fix for a crashing bug must not be included if it breaks binary compatibility.) + +It is not necessary to include every change meeting these criteria, and in +general the focus should be on addressing security issues, crashing bugs, +regressions and serious installation issues. The temptation to include a +plethora of minor changes that don't affect the installation or execution of +perl (e.g. spelling corrections in documentation) should be resisted in order +to reduce the overall risk of overlooking something. The intention is to +create maintenance releases which are both worthwhile and which users can have +full confidence in the stability of. (A secondary concern is to avoid burning +out the maint-pumpking or overwhelming other committers voting on changes to be +included (see L</"Getting changes into a maint branch"> below).) + +The following types of change may be considered acceptable, as long as they do +not also fall into any of the "unacceptable" categories set out below: + =over =item * -New releases of maint should contain as few changes as possible. -If there is any question about whether a given patch might merit -inclusion in a maint release, then it almost certainly should not -be included. +Patches that fix CVEs or security issues. These changes should +be run through the [email protected] mailing list +rather than applied directly. =item * -Portability fixes, such as changes to Configure and the files in -hints/ are acceptable. Ports of Perl to a new platform, architecture -or OS release that involve changes to the implementation are NOT -acceptable. +Patches that fix crashing bugs, assertion failures and +memory corruption but which do not otherwise change perl's +functionality or negatively impact performance. =item * -Acceptable documentation updates are those that correct factual errors, -explain significant bugs or deficiencies in the current implementation, -or fix broken markup. +Patches that fix regressions in perl's behavior relative to previous +releases, no matter how old the regression, since some people may +upgrade from very old versions of perl to the latest version. =item * -Patches that add new warnings or errors or deprecate features -are not acceptable. +Patches that fix anything which prevents or seriously impacts the build +or installation of perl. =item * -Patches that fix crashing bugs, assertion failures and -memory corruption that do not otherwise change Perl's -functionality or negatively impact performance are acceptable. +Portability fixes, such as changes to Configure and the files in +the hints/ folder. =item * -Patches that fix CVEs or security issues are acceptable, but should -be run through the [email protected] mailing list -rather than applied directly. +Minimal patches that fix platform-specific test failures. =item * -Patches that fix regressions in perl's behavior relative to previous -releases are acceptable. +Documentation updates that correct factual errors, explain significant +bugs or deficiencies in the current implementation, or fix broken markup. =item * Updates to dual-life modules should consist of minimal patches to -fix crashing or security issues (as above). +fix crashing bugs or security issues (as above). Any changes made to +dual-life modules for which CPAN is canonical should be coordinated with +the upstream author. + +=back + +The following types of change are NOT acceptable: + +=over =item * -Minimal patches that fix platform-specific test failures or build or -installation issues are acceptable. When these changes are made -to dual-life modules for which CPAN is canonical, any changes -should be coordinated with the upstream author. +Patches that break binary compatibility. (Please talk to a pumpking.) =item * -New versions of dual-life modules should NOT be imported into maint. -Those belong in the next stable series. +Patches that add or remove features. =item * -Patches that add or remove features are not acceptable. +Patches that add new warnings or errors or deprecate features. =item * -Patches that break binary compatibility are not acceptable. (Please -talk to a pumpking.) +Ports of Perl to a new platform, architecture or OS release that +involve changes to the implementation. + +=item * + +New versions of dual-life modules should NOT be imported into maint. +Those belong in the next stable series. =back +If there is any question about whether a given patch might merit +inclusion in a maint release, then it almost certainly should not +be included. =head2 Getting changes into a maint branch @@ -337,6 +363,17 @@ a specific commit along with a rationale for doing so and at least two other committers respond to the list giving their assent. (This policy applies to current and former pumpkings, as well as other committers.) +Other voting mechanisms may be used instead, as long as the same number of +votes is gathered in a transparent manner. Specifically, proposals of +which changes to cherry-pick must be visible to everyone on perl5-porters +so that the views of everyone interested may be heard. + +It is not necessary for voting to be held on cherry-picking perldelta +entries associated with changes that have already been cherry-picked, nor +for the maint-pumpking to obtain votes on changes required by the +F<Porting/release_managers_guide.pod> where such changes can be applied by +the means of cherry-picking from blead. + =head1 CONTRIBUTED MODULES -- Perl5 Master Repository
