develooper Front page | perl.perl5.porters | Postings from January 2011

Re: let's be stricted with maint doc changes

Thread Previous | Thread Next
January 4, 2011 00:12
Re: let's be stricted with maint doc changes
Message ID:
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"
>   "Fix type" -- specifically "even If the input" s/If/if/
> 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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About