On 26 February 2015 at 05:26, Ruby Loo <rlooya...@gmail.com> wrote:
> Hi,
>
> I was wondering what people thought about patches that only fix grammatical
> issues or misspellings in comments in our code.
>
> I can't believe I'm sending out this email, but as a group, I'd like it if
> we had  a similar understanding so that we treat all patches in a similar
> (dare I say it, consistent) manner. I've seen negative votes and positive
> (approved) votes for similar patches. Right now, I look at such submitted
> patches and ignore them, because I don't know what the fairest thing is. I
> don't feel right that a patch that was previously submitted gets a -2,
> whereas another patch gets a +A.
>
> To be clear, I think that anything that is user-facing like (log, exception)
> messages or our documentation should be cleaned up. (And yes, I am fine
> using British or American English or a mix here.)
>
> What I'm wondering about are the fixes to docstrings and inline comments
> that aren't externally visible.
>
> On one hand, It is great that someone submits a patch so maybe we should
> approve it, so as not to discourage the submitter. On the other hand, how
> useful are such submissions. It has already been suggested (and maybe
> discussed to death) that we should approve patches if there are only nits.
> These grammatical and misspellings fall under nits. If we are explicitly
> saying that it is OK to merge these nits, then why fix them later, unless
> they are part of a patch that does more than only address those nits?
>
> I realize that it would take me less time to approve the patches than to
> write this email, but I wanted to know what the community thought. Some
> rule-of-thumb would be helpful to me.
>
> Thoughts?

I think improvements are improvements and we should welcome them - and
allow single +2/+A so long as they are not touching code.

-Rob


-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to