From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.15220.1679045635571089788 for ; Fri, 17 Mar 2023 02:33:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=C2xelubY; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679045634; 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: in-reply-to:in-reply-to:references:references; bh=g4OuzKDASAInRCYr7GisEkjCLKWcs7SiakbNUF+oSj0=; b=C2xelubYI7/tcS8KJrKdKIwHybw5P9Np0OKZnu0d3lL3Grc8ZrT+5gGTyay3nWMR/X2tAB iDy7P6ZlSrPngX933laq4tFHcws8kmO/oMead9CRdTXkv6uATFgPH+kjYAeiqKiECujha7 SZFl9DGCpT8rGccnWmg1NDFUuWshssk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-211-YxclBreKOLKw9_VRhvbTIg-1; Fri, 17 Mar 2023 05:33:49 -0400 X-MC-Unique: YxclBreKOLKw9_VRhvbTIg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5191E185A78F; Fri, 17 Mar 2023 09:33:49 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.89]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E279040C6E67; Fri, 17 Mar 2023 09:33:48 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 9905A1800617; Fri, 17 Mar 2023 10:33:47 +0100 (CET) Date: Fri, 17 Mar 2023 10:33:47 +0100 From: "Gerd Hoffmann" To: devel@edk2.groups.io, rebecca@bsdio.com Cc: michael.d.kinney@intel.com, Marvin =?utf-8?Q?H=C3=A4user?= Subject: Re: [edk2-devel] [edk2-platforms] Enable GitHub PR, protected branches, and 'push' label Message-ID: <20230317093347.gi65s3qu5vzzilzn@sirius.home.kraxel.org> References: <1336.1678919068042837404@groups.io> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Mar 16, 2023 at 01:59:49PM -0600, Rebecca Cran wrote: > Is this still a requirement since Laszlo's departure from the project? > > I seem to recall it was him who made it a sticking point of moving to a > GitHub PR workflow originally with the requirement to have emails of > everything. I think it is very useful to have everything on the mailing list for a number of reasons: (1) In my experience reviewing patches, especially more complex ones, works better in email than in github PR workflows. (2) github doesn't preserve stuff like a mail archive does. When a patch series goes through multiple revision github only preserves the latest revision which was actually merged. (3) Search engines seem to be better in indexing mail list archives than github pull requests. Nevertheless I see some room for improvement in our current workflow. Developers often open a PR anyway for to run the CI. So maybe we could automate sending the emails and also avoid running CI twice by avoiding both developer and maintainer opening a PR, with a workflow like this: * developer opens a draft PR to run CI for the patch series. * when the series passes CI and is ready un-draft the PR. * github action sends the patch series to the edk2-devel list for review (maybe only after CI passed ...). * patch review happens on the list. * in case the developer pushes updates to the branch in response to review comments the github action posts v2/v3 of the series too. * once review is done merge the PR. take care, Gerd