On 02/26/2015 06:47 AM, Lucas Alvares Gomes wrote: > Hi, > > I never had a strong opinion on this but reading what Jay said makes > sense to me. I also like Robert suggestion about having a single +2/+A > for such small changes.
+A > > Cheers, > Lucas > > On Wed, Feb 25, 2015 at 11:22 PM, Robert Collins > <[email protected]> wrote: >> On 26 February 2015 at 05:26, Ruby Loo <[email protected]> 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 <[email protected]> >> Distinguished Technologist >> HP Converged Cloud >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
