Front page | perl.perl5.porters |
Postings from January 2011
On Mon, Jan 03, 2011 at 06:41:54PM -0500, Ricardo Signes wrote: > > 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." I never read it that way. I thought documentation updates are acceptable as it seems extremely unlikely for a documentation patch to actually introduce a bug. > > 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. Typo fixes and many other documentation improvements seems low hanging, non-dangerous fruit to me. I'd prefer them to be part of a maint release. And I think immediately applying instead of voting is the way to go. AbigailThread Previous | Thread Next