Front page | perl.perl5.porters |
Postings from January 2011
I just finished a run through cherrymaint, applying a lot of the approved-but-unapplied changes, or tightly-related changes that were seconded but not approved. I found one or two commits that I think definitely belonged in 5.12.3, and a lot of stuff that seemed to be a waste of time. perlpolcy says: 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. ... Documentation updates are acceptable. "are acceptable" should read "are grudgingly acceptable." Or maybe, "are acceptable if they fix broken links, broken Pod, or correct factual errors." Why am I reviewing commits for the critical-fixes-only branch for things like this: "remove trailing spaces in perlvar.pod" http://perl5.git.perl.org/perl.git/commitdiff/b0c1862 "Fix type" -- specifically "even If the input" s/If/if/ http://perl5.git.perl.org/perl.git/commitdiff/c8dbf8c These are incredibly small improvements, if improvements at all for a branch that really is meant only to get serious build and bug fixes. When considering porting patches back, I suggest this rubric for voting? * will this commit close a security vulnerability? * will this commit fix a serious bug or a recent regression? * will this commit make unclear or false documentation correct again? If all of these questions are answered "no" then remember that by not rejecting the commit, you are making work for other people with seemingly very limited value. Finally, typo fixes may be a case where the benefit is "we look less stupid," which does have some value. If we want to persue that, I suggest that we allow those to be immediately applied, so that they do not need to be voted on, reviewed, and correctly ordered in the future. For my part, though, I'd rather just let the typo get fixed in the next major release. -- rjbsThread Next