Open Stack

Jay,
I can only confirm your point of view.
I personally landed such a patch yesterday and saw it as an easy way to get
familiar with Gerrit.

My goal being to land some more complex patches in the near future.

Bernard

On Wed, Feb 25, 2015 at 12:37 PM, Doug Hellmann <doug at doughellmann.com>
wrote:

>
>
> On Wed, Feb 25, 2015, at 12:36 PM, Jay Faulkner wrote:
> >
> > > On Feb 25, 2015, at 10:26 AM, Ruby Loo <rlooyahoo at 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.
> > >
> >
> > I personally always ask this question: does it make the software better?
> > IMO fixing some of these grammatical issues can. I don’t think we should
> > actively encourage such patches, but if someone already did the work, why
> > should we run them away? Many folks use patches like this to help them
> > learn the process for contributing to OpenStack and I’d hate to run them
> > away.
> >
> > These changes tend to bubble up because they’re an easy way to get
> > involved. The time it takes to review and merge them in is an investment
> > in that person’s future interest in contributing to OpenStack, or
> > possibly open source in general.
>
> +1
>
> We need to keep this sort of thing in mind. If the patch is fairly
> trivial, it's also fairly trivial to review. If it is going to cause a
> more complex patch to need to be rebased, suggest that the proposer
> rebase their patch on top of the complex patch to avoid problems later
> -- that's teaching another lesson, so everyone benefits.
>
> Doug
>
> >
> > -Jay
> >
> >
> > > Thoughts?
> > >
> > > --ruby
> > >
> __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150225/436cefca/attachment.html>