From dev-return-31154-archive-asf-public=cust-asf.ponee.io@geode.apache.org Fri May 31 20:44:14 2019 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 [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 23BA2180627 for ; Fri, 31 May 2019 22:44:14 +0200 (CEST) Received: (qmail 90619 invoked by uid 500); 31 May 2019 20:44:13 -0000 Mailing-List: contact dev-help@geode.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@geode.apache.org Delivered-To: mailing list dev@geode.apache.org Received: (qmail 90608 invoked by uid 99); 31 May 2019 20:44:13 -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; Fri, 31 May 2019 20:44:13 +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 8C02B1A34A1 for ; Fri, 31 May 2019 20:44:12 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled 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 LwZNBrc1RLV7 for ; Fri, 31 May 2019 20:44:10 +0000 (UTC) Received: from mx0b-00296801.pphosted.com (mx0b-00296801.pphosted.com [148.163.153.148]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 2001E5F180 for ; Fri, 31 May 2019 20:44:10 +0000 (UTC) Received: from pps.filterd (m0114584.ppops.net [127.0.0.1]) by mx0b-00296801.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4VKaa71029911 for ; Fri, 31 May 2019 20:44:09 GMT Received: from mail-ot1-f70.google.com (mail-ot1-f70.google.com [209.85.210.70]) by mx0b-00296801.pphosted.com with ESMTP id 2su7w1r7te-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 31 May 2019 20:44:08 +0000 Received: by mail-ot1-f70.google.com with SMTP id a21so5046774otl.14 for ; Fri, 31 May 2019 13:44:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1bcKtmMnpt1zNr8jNcLe70f1LVUpo2gFA6ewcxe69rg=; b=RQTdBFc5ydO9eUfUrbgAWGoG2gW0DcRGVMoX6Zz4k3AjYE1UJIog7yK37ME8Vcs64Z ASDj2il1xzlh/K+SIrkhf8kolxHNvkQzmeMGLYU7Rl/IekmzEevIPFFyhPtQOs0ipwTz b6dZo5mSMgnlNloe42JmBWYpCgrJxxQ10d83XCNuVvkTCfxLnrWEwzrk5MhbKN1hIMhZ ovUVjNiOGNF0lfo5nigNSmjtOtQfDqkahst8iMLn8dwrU1iN7XVbtLe2/3lCvWKhFht3 WyuRG/ulj+UiNm/bydtMRn67fNpd6kvraz+Iq92xmvP5II+y3e/jIYFsWm8pSZOdNiMY XDng== X-Gm-Message-State: APjAAAVewhUK08T6GG7fQzZLjAgLQ7Lygf3/kT/IZtizqsIGq79PI2Fr mWKI+lRIuvfzwCsfcuhlZCjZ9qj1i242k5VLhnyoj+puQXXNwAc+GCJkdEeySuGsI23uEmb+jIQ LAPka/H43jA4IKEBak8pVlty3DMn38HWv08NBt5dIfPbSuj6PqpkAQoo= X-Received: by 2002:a05:6830:16cc:: with SMTP id l12mr3434873otr.25.1559335447845; Fri, 31 May 2019 13:44:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqy1uPY+i4MRRh3LgApo+7fsixvdWV5OiO2EkmhY096DQ3s5/1TOI3yNgo4YFJQ4craV04tH5gjrV6dQRzdnT6k= X-Received: by 2002:a05:6830:16cc:: with SMTP id l12mr3434848otr.25.1559335447454; Fri, 31 May 2019 13:44:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nabarun Nag Date: Fri, 31 May 2019 13:43:56 -0700 Message-ID: Subject: Re: what is the best way to update a geode pull request To: dev@geode.apache.org Content-Type: multipart/alternative; boundary="0000000000006e7b1d058a3513ff" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-05-31_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905310125 --0000000000006e7b1d058a3513ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In my opinion, I am okay will multiple commits within a PR. But please do squash them to a single commit when it is pushed to develop. This helps us a ton if it is single commit. - bisect operations are easier when it is a single commit during major failure analysis. - cherrypick is easier when it is one commit. I even don=E2=80=99t prefer merge commit messages : - none of the big ASF projects do it. - visualizing on tools is bit skewed. - difficult to analyze failures . I would like to reiterate Dan=E2=80=99s statement on emphasis on people and= empathy over blanket process and rules. Regards Naba On Fri, May 31, 2019 at 1:32 PM Helena Bales wrote: > +1. I would guess that it is the checklist as part of the PR that is > confusing people. > > The other reason that history gets rewritten is when force pushing after = a > rebase. While fast-forwarding is necessary on occasion, this can be > accomplished without rewriting history by using a merge. > > As part of our document on making PRs, we should include instructions on > how to handle the situation where fast-forwarding is necessary, explicitl= y > discourage the use of merges and force-pushes once a PR has been opened, > and some guidelines regarding the appropriate number of commits when the = PR > is initially opened. Once we have these guidelines, it would be helpful t= o > link to them from the PR checklist that we currently have, and rework the > checklist so that it is in line with our desired process. > > On Fri, May 31, 2019 at 1:20 PM Darrel Schneider > wrote: > > > Something I have noticed is that often when I have requested changes be > > made to a pull request is that the changes are force pushed ask a singl= e > > commit to the pr. I would actually prefer that the changes show up as a > new > > commit on the pr instead of everything being rebased into one commit. > That > > makes the history of the pr easier to follow and make it easy to see wh= at > > has changed since the previous review. What do others think? Have we do= ne > > something that makes contributors think the pull request has to be sing= le > > commit? I know the initial pull request is supposed to be but from then > on > > I'd prefer that we wait to squash when we merge it to develop. > > > --0000000000006e7b1d058a3513ff--