From dev-return-111350-archive-asf-public=cust-asf.ponee.io@cloudstack.apache.org Wed May 2 13:23:49 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id B9C0718065D for ; Wed, 2 May 2018 13:23:48 +0200 (CEST) Received: (qmail 70866 invoked by uid 500); 2 May 2018 11:23:47 -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 70848 invoked by uid 99); 2 May 2018 11:23:46 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 May 2018 11:23:46 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 5705B1A0695 for ; Wed, 2 May 2018 11:23:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id zDov0WTWAUam for ; Wed, 2 May 2018 11:23:44 +0000 (UTC) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id BEAE25F5E0 for ; Wed, 2 May 2018 11:23:43 +0000 (UTC) Received: by mail-oi0-f51.google.com with SMTP id v2-v6so12581025oif.3 for ; Wed, 02 May 2018 04:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=g3cvsoaQT2bkdp8LXk83aMdxDhanT07n6MgBFVpWef8=; b=CkFmFT6w2uZ72/FgC4AK/BOtVC1+34Wx6fPu/xngjZNmdCRZmmKJm+pL930/X8IJmS SxLmXA3BgOkXOR9Rscb9pU9YjGXu+E2IWtLs8FvoJbxiwOgwSQknEwB43Jn7UPL3HcyM pSDUVjlMCeMEAZDexBTxtZ4L8AjLbZNI+UDTracVEnB/nmYA20VlzjbH7PWGBLoYUADF UzkU5SjCleyKrDBgqV1GoYkN7KaL9IoSaXoPACiP4gPjqXnJZndi9rSeL24L2vp7HU0o Ri9tJ3PdCA8yaV0AEfbkf/DS3+h/okq59CK9/dhxf/veLuszg4HpFWwcVKkRp9CtNJiW ZJBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=g3cvsoaQT2bkdp8LXk83aMdxDhanT07n6MgBFVpWef8=; b=BI2nyufMOHKu5roLkyS+NGEKUkqNYOy0pXxbd0U8g1LY51HEuXQNdxV/X9VgAcmC9u /dUBC8+l9i2NJ4Aw19dhhAXVc1+BmmNwUTaJYBgq2IQ5X90u/hPOAS2w+bJsOfsdMY7C Dj3BdTzfrVDmbfLcpgiHBtqUjAM7ouiVzTE2IOsvxUh5Xm1kTdgH8xg3zp1jxs/bwJQ3 ermX1DbpRkx3iI8LET+r880EuBJF2KH6aXxpM/feFViR4jlk5J68XWPkxyg03GiAUjlR xBTXGwXBD18YTV0by+f70TzST0rab30T9XP5mB2HiFdn7qH7W8m1v+bPBX2v5CVHbCBW nPXA== X-Gm-Message-State: ALQs6tB5+I1DvQrIx2+Abi8A7PhRa9vYRNDfUKzYxUMVPVK5j9hWpufB J/hL8wUEPjLlGUJROpHwdDCZUB15omIO5RmPZqKERY/L X-Google-Smtp-Source: AB8JxZqY1o7j7+AlgYYfm4TU8cLohXy0lNIh/eVzjXQnBPgALdNoUC8a8rZ2QqORRkg8PmTX0Vp8FJjpg7Q+JH1KVPg= X-Received: by 2002:aca:c102:: with SMTP id r2-v6mr10772868oif.232.1525260222189; Wed, 02 May 2018 04:23:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ca1:0:0:0:0:0 with HTTP; Wed, 2 May 2018 04:23:41 -0700 (PDT) In-Reply-To: <20707E4C-D76A-477C-895F-F1D17837F206@netapp.com> References: <728E93F4-20E5-4B1F-928C-FDB27B1E6999@shapeblue.com> <01ff3318-e34d-915a-7281-ddee8414f924@renemoser.net> <20707E4C-D76A-477C-895F-F1D17837F206@netapp.com> From: =?UTF-8?Q?Rafael_Weing=C3=A4rtner?= Date: Wed, 2 May 2018 08:23:41 -0300 Message-ID: Subject: Re: [DISCUSS] new way of github working To: dev Content-Type: multipart/alternative; boundary="000000000000bbdff5056b3751e7" --000000000000bbdff5056b3751e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we are on the same page here. There is only one thing that is different from what we are doing in PRs. > Before you create a PR, squash all applicable commits to make it more > readable for reviewers > I would suggest not squashing everything before creating the PR. I mean, do the following when coding: - disable your auto formatter (in Eclipse you can just disable the save actions) if you are going to change a class that might need formatting - do the changes - create a commit for the main changes of the PR - enable the auto formatter and formatting the change files - create a commit for formatting and cleanup changes - then create the PR Separating formatting/cleanups commits makes it easier for reviewers to evaluate changes. On Tue, May 1, 2018 at 3:53 PM, Tutkowski, Mike wrote: > Hi everyone, > > We had a good conversation going here. Maybe we can continue it, get some > level of reasonable consensus, and implement it (if, in fact, the consens= us > is a change from what we currently have). > > My suggested approach is the following: > > Before you create a PR, squash all applicable commits to make it more > readable for reviewers. Once reviews start coming in and you start making > changes, push new commits on top of the prior ones (do not squash at this > point). This will make it easier for reviewers to confirm that you and th= ey > are on the same page with regards to what was changed. When you need to > draw in changes from the base branch, rebase your commits on top of it. > When the PR is given a LGTM by 2+ reviewers and passed the necessary > regression tests, it should be squashed and then merged. I see the > evolution of commits during the life of the PR as a temporary sandbox of > history that is no longer required once the PR has been completed. > > I think that process should cover the vast majority of our PRs. > > There are usually some exceptions to the rule, however. When this happens= , > discuss your situation with the reviewers and bring any concerns to the > mailing list before deviating from the standard process. > > Thoughts? > Mike > > On 1/15/18, 1:47 PM, "Rene Moser" wrote: > > > > On 01/15/2018 09:06 PM, Rafael Weing=C3=A4rtner wrote: > > Daan, > > > > Now that master is open for merges again, can we get a feedback > here? It > > might be interesting to find a consensus and a standardize way of > working > > for everybody before we start merging things in master again =E2=80= =A6 > > +1 to allow merge commits on master branch to keep history of a serie= s > of patches when they help to understand the change. > > Ren=C3=A9 > > > > > --=20 Rafael Weing=C3=A4rtner --000000000000bbdff5056b3751e7--