Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 59913193A2 for ; Fri, 8 Apr 2016 18:12:56 +0000 (UTC) Received: (qmail 40186 invoked by uid 500); 8 Apr 2016 18:12:51 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 40129 invoked by uid 500); 8 Apr 2016 18:12:51 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 40118 invoked by uid 99); 8 Apr 2016 18:12:50 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Apr 2016 18:12:50 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id 8A160DFBED; Fri, 8 Apr 2016 18:12:50 +0000 (UTC) From: swill To: dev@cloudstack.apache.org Reply-To: dev@cloudstack.apache.org References: In-Reply-To: Subject: [GitHub] cloudstack pull request: Taking fast and efficient volume snapshot... Content-Type: text/plain Message-Id: <20160408181250.8A160DFBED@git1-us-west.apache.org> Date: Fri, 8 Apr 2016 18:12:50 +0000 (UTC) Github user swill commented on the pull request: https://github.com/apache/cloudstack/pull/1403#issuecomment-207542455 I have not seen a style guide, but I have not looked. I have just seen a bunch of PRs recently and there seems to be a consistent work to remove the `_`s in the code, so I figured I would mention it. To me, this is not a reason not to merge the code, but I agree it would be good to know what the style should be so I can start enforcing it so we can start working towards consistent styling. I am not requiring the LGTM code reviews to come from committers. If you are active on on Github and are adding value to the project by reviewing code, I am willing to work with that. Because I am not being strict about who is reviewing the code, I am also enforcing at least 2 people review the code so I get more eyes on ever PR. As for the squash. It may make sense to have some history, but there are a lot of commits in there that are entirely useless outside the greater context of this PR. To me, the final version of the code merged trumps all. If it is squashed then we can more easily evaluate the changes associated with this commit later. If you think there are some points in the history of this feature that make sense to be called out as important, you can squash into 3 or 4 commits, but 43 commits for a single PR is crazy and will add more confusion than clarity. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastructure@apache.org or file a JIRA ticket with INFRA. ---