From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web09.1313.1575449804597241808 for ; Wed, 04 Dec 2019 00:56:44 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gK3kx0EO; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575449803; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=h5+IPCWpF6HkdTxptIeGor0tONAU32GBcKsU7RGP8J4=; b=gK3kx0EOt8OcTpjVl7RWbTF6toQ1DCOo6FiC2wooxTvr2gfsIcxuEQBIchtM/9/kR242PQ ucLtZwFy9LP4Tz/eFsSWIBiUbqWfjkm4NF/NTmtjPnDwvyidqNjNlmOZiisAS0y7MLGAev TOAIwW0tdQpuM1a/6n7J9NGCEfC4rlI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-23-sScnpJf5M2KD9LntZ7_Wlg-1; Wed, 04 Dec 2019 03:56:39 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DF18F102312A; Wed, 4 Dec 2019 08:56:37 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-154.ams2.redhat.com [10.36.116.154]) by smtp.corp.redhat.com (Postfix) with ESMTP id 17D565C1B0; Wed, 4 Dec 2019 08:56:35 +0000 (UTC) Subject: Re: [edk2-devel] [Patch wiki v2] EDK II CI: Update Phase 1 details and admin settings To: "Kinney, Michael D" , "devel@edk2.groups.io" Cc: Sean Brogan , Bret Barkelew , "Gao, Liming" , Andrew Fish , Leif Lindholm References: <20191202175630.12788-1-michael.d.kinney@intel.com> From: "Laszlo Ersek" Message-ID: Date: Wed, 4 Dec 2019 09:56:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-MC-Unique: sScnpJf5M2KD9LntZ7_Wlg-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 12/03/19 22:53, Kinney, Michael D wrote: >> -----Original Message----- >> From: Laszlo Ersek >> Sent: Tuesday, December 3, 2019 9:08 AM >> To: devel@edk2.groups.io; Kinney, Michael D >> >> Cc: Sean Brogan ; Bret >> Barkelew ; Gao, Liming >> ; Andrew Fish ; >> Leif Lindholm >> Subject: Re: [edk2-devel] [Patch wiki v2] EDK II CI: >> Update Phase 1 details and admin settings >>> +3) TianoCore EDK II Maintainers Team permissions >> reduced from 'Write" to "Triage" >>> +4) EDK II Maintainers must use GitHub pull request >> with 'push' label to request >>> + a branch to be strict rebase merged into >> `edk2/master`. If all checks pass, >> >> Perhaps replace "strict rebase" with "strict fast- >> forward"? > > Please look at these descriptions: > > https://doc.mergify.io/actions.html#git-merge-workflow-and-mergify-equivalent-configuration > > We are currently using strict: true, method: rebase > > https://github.com/tianocore/edk2/blob/master/.mergify/config.yml > > Let me know if you what is the best way to describe this. > I am currently using terms for the Mergify settings and not > the git terminology. Thanks for the link to the mergify documentation. The article lists 9 strategies. From these, we can rule out all that do *not* use (on base branch) $ git merge --ff head as last step. This leaves us with 5 strategies. Then we can rule out all methods that mention "Squash all commits". This leaves us with two strategies: (1) (on head branch) $ git rebase base (on base branch) $ git merge --ff head (2) (on head branch) $ git merge --no-ff base (on head branch) # Wait for CI to go green (on head branch) $ git rebase base (on base branch) $ git merge --ff head Among these, (1) looks like the obvious choice to me ("method: rehead"). However, I realize that (1) does not run CI. Which leaves us with (2) only. And that's what "strict: true, method: rebase" selects in fact. Note that (2) is basically (1), prefixed with two additional steps, for CI. Now, what I don't understand in (2) is why it first merges "base" (i.e. edk2 master) into "head" (i.e. the topic branch), before setting off CI. Instead of that, I would propose inserting the CI step between the two steps of (1): as follows: (*) (on head branch) $ git rebase base (on head branch) # Wait for CI to go green (on base branch) $ git merge --ff head Either way, given the current palette of strategies, I agree that "strict: true, method: rebase" is our only choice. The "strict merge" explanation at states the correct *goal*, but I don't think the implementation is ideal. The end state that we're going to push to the repository consists of the topic branch rebased on the master branch. But that's not what the "strict merge" strategy subjects to CI: instead, it merges the (possibly advanced) master branch temporarily back into the topic branch. So... in light of this, I think my suggestion to use the "native" git terminology would actually be incorrect. It would be suggesting a workflow (*) that mergify does not seem to implement at this time. So ultimately I agree with your current wording. May I ask for just one improvement: wherever you use the term "strict rebase merged", can you please turn that into a link to ? Thank you, Laszlo