From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 4FFD4740046 for ; Mon, 30 Oct 2023 10:45:11 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=lcUkTbELcen0NgZrcnloONM9o/E1yY7OCPUIj8UKBUA=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1698662710; v=1; b=ixMpV9a+RC52t2MuZ7NA2D4i3UeP633L9RNAsxDAPwxY3VQHdV4iyhrJtf/Yvc+Wzu4px3tY bquSzh9/2JCK5zDGsWFfTK//PGQ9h/L++npOxhdVx4VS+uNCzasjbAjooOyrXktdZqURFFtARX2 RpJcuIGc1VQ59U74FS6AiNps= X-Received: by 127.0.0.2 with SMTP id wkY3YY7687511xnpb9uiOIp1; Mon, 30 Oct 2023 03:45:10 -0700 X-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.web10.145695.1698662709210622499 for ; Mon, 30 Oct 2023 03:45:09 -0700 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-687-eSylnUoCM6W9THEKDayvGg-1; Mon, 30 Oct 2023 06:45:02 -0400 X-MC-Unique: eSylnUoCM6W9THEKDayvGg-1 X-Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 30B8E101A550; Mon, 30 Oct 2023 10:45:01 +0000 (UTC) X-Received: from [10.39.194.199] (unknown [10.39.194.199]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 643B32026D4C; Mon, 30 Oct 2023 10:44:57 +0000 (UTC) Message-ID: Date: Mon, 30 Oct 2023 11:44:56 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members To: "Yao, Jiewen" , "Kinney, Michael D" , "jejb@linux.ibm.com" , "devel@edk2.groups.io" , "pedro.falcato@gmail.com" Cc: Andrew Fish , Leif Lindholm , "Warkentin, Andrei" , "West, Catharine" , "Bi, Dandan" , Daniel Schaefer , David Woodhouse , "De, Debkumar" , "Dong, Eric" , "Jiang, Guomin" , "Wu, Hao A" , "Wang, Jian J" , "Justen, Jordan L" , Julien Grall , Peter Grehan , "Zhang, Qi1" , "Ng, Ray Han Lim" , Stefan Berger , "Hou, Wenxing" , "Lu, Xiaoyu1" References: <20231028192330.1031-1-michael.d.kinney@intel.com> <99615ab9-f669-5ac8-fafd-f154e8af5da8@redhat.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: sAtqdtYYxgc4izRGxfzaGspTx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=ixMpV9a+; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 10/30/23 03:40, Yao, Jiewen wrote: > Thanks Mike. I am reading the WIKI page. >=20 >=20 >> and/or provides testing or regression testing for the Package (or some m= odules thereof), in certain platforms and environments. >=20 > [Jiewen] Are we expecting Reviewer to provide testing or regression testi= ng for the package? > Is that what the reviewer *commits* to do? > For example, Maintainer may ask the reviewer to do some testing, right? It depends on the reviewer's individual commitment. First of all, the burden of testing / regression-testing, to a reasonable extent [1], is on the submitter. [1] In some cases, the submitter cannot test the code they modify in all possible environments / circumstances. In such cases, the submitter should test the change code wherever they can, as widely as they can, and be upfront (in the commit message) about lacking coverage in other environments they might be aware of. It is then fine for the maintainer (or even reviewer) to ask others for further / wider testing, but trying to saddle someone with that testing as an *obligation* will never fly. That would only alienate people from contributing. This was the primary reason for splitting Xen code as sharply as possible from non-Xen code in both ArmVirtPkg and OvmfPkg. Xen and QEMU/KVM are so different environments, with so distinct audiences, that keeping code common was *worse* than duplicating and customizing code. We could never *sufficiently* regression-test our changes for each other. It was best to separate those areas of interest. Demanding that I regression-test on Xen, or that Anthony or Julien regression-test on QEMU/KVM, would have lead nowhere. Second, the level of commitment varies. A reviewer may have a fleeting interest in a module (just want to be in the loop), or else they may be completely invested in it, and they might actually prefer being a maintainer. For example, I had seen many bad regressions in OVMF due to UefiCpuPkg patches, thus, even thouogh I absolutely didn't welcome the additional responsibility, I asked to be added as a Reviewer for UefiCpuPkg. With that, I wanted to formalize my request to be CC'd on all UefiCpuPkg patches, but I also committed to regression testing, and maybe even reviewing, those patches. It worked out quite well, but of course I was still selective in what I would review and test. If I could immediately determine that the patch modified code in UefiCpuPkg that never ran on (or wasn't even built into) OVMF, I would clearly state on the list that I'd not review or test the patch, i.e., that nobody should wait for me. >=20 >=20 >> Reviewer is responsible for timely responses on emails addressed to them= (preferably less than calendar week). >=20 > [Jiewen] > Is that what the reviewer *commits* to do? What I think we can expect a reviewer to *commit* to is to say *something* reasonably quickly. The whole idea is to support others in making a *decision*, in making progress. So the "something" the reviewer says may well be: - "this does not apply to the area I have expertise or interest in, so please proceed with this patch without my feedback (testing or review or opinion etc)" - "I don't have time for this right now, so please go ahead; if it breaks, we'll figure it out later" (the maintainer need not accept this, and might want to block the patch independently for a bit longer, until someone else provides the desired review or testing, but the reviewer is still totally OK to say this) - "please give me a few more days to review this set". > For example, Maintainer may ask the reviewer to provide feedback, right? IMO, the maintainer is welcome to request feedback, of course; that's presumably why the reviewer wanted to be listed in Maintainers.txt in the first place. Laszlo -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110305): https://edk2.groups.io/g/devel/message/110305 Mute This Topic: https://groups.io/mt/102245264/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-