From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web11.1047.1601315755279867447 for ; Mon, 28 Sep 2020 10:55:55 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=H4I6YIgA; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1601315754; 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=jahnnDYOI/yKPK1ZsEgNzz9ali+X3d40W6nKepd1IR0=; b=H4I6YIgAyxE1us4H2qgxIkaQYaOMRTUECV3UkD1+3uVUPGCvi1CB3RBG7ilNkrlCQW+6ce mTbfuytR7lcPTgvfg5Dbfa+Ve0Yt3hWggd6avFkKiQhz/8VfN0T4J8vDFpmPVFQsBhidUQ 2JtpK2xhF2B6pTEJouAXsZcnKBslvh8= 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-471-gzrPbFXHMZejF5zY4tVKNQ-1; Mon, 28 Sep 2020 13:55:51 -0400 X-MC-Unique: gzrPbFXHMZejF5zY4tVKNQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0AC66103098C; Mon, 28 Sep 2020 17:55:49 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-138.ams2.redhat.com [10.36.113.138]) by smtp.corp.redhat.com (Postfix) with ESMTP id A7FC173666; Mon, 28 Sep 2020 17:55:43 +0000 (UTC) Subject: Re: [edk2-devel] more development process failure [was: UefiPayloadPkg: Runtime MMCONF] To: "Dong, Guo" , Andrew Fish , edk2-devel-groups-io , "Ni, Ray" Cc: "Yao, Jiewen" , "gaoliming@byosoft.com.cn" , "marcello.bauer@9elements.com" , "Kinney, Michael D" , "Leif Lindholm (Nuvia address)" , "Doran, Mark" , "Guptha, Soumya K" References: <20200818082421.6168-1-marcello.bauer@9elements.com> <11b4d671-7c5e-0ef3-0d2f-13ef605f1eaf@redhat.com> <000e01d68c94$bb92d920$32b88b60$@byosoft.com.cn> <31e807dc-6217-f3b6-995b-ab10f4ce789e@redhat.com> From: "Laszlo Ersek" Message-ID: <98fd8c76-0815-88b9-8d63-f2092efc0997@redhat.com> Date: Mon, 28 Sep 2020 19:55:43 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 09/26/20 02:34, Dong, Guo wrote: > > Sorry to have a long email thread since my merge and thanks all for > the comments. > In general, I still feel current process is a little complicated for > the maintainers who don't daily work on EDK2 like me. I have less > than %5 of time spent on open source EDK2 UefiPayloadPkg since I focus > on bootloaders. It would be great if I could spend the time mainly on > code review instead of the process as of now. I think this is a 100% reasonable request; it would mean that your "M" role should be replaced with an "R" role under "UefiPayloadPkg", and then your co-maintainers (Maurice and Benjamin) would be responsible for pushing the patches that you review. > > Even after I read > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process#the-maintainer-process-for-the-edk-ii-project > as Liming pointed out, Some info is still not clear for me. E.g. > what's the purpose for putting cover letter to patch set pull request > (it looks we could not trace to this PR from code)? is it mandatory or > optional? There are two questions to consider here, actually. I do not insist that the PRs have sensible descriptions, at this stage. However, if *some* maintainers are expected to populate the PRs with sensible descriptions, then *all* of them should. So the reason I'm asking you to add sensible descriptions to PRs, at this stage, is not because I'm 100% committed to duplicating information there. Instead, the reason is that Mike has asked me to do so, and therefore you (and everyone else) should do so as well. Alternatively (a perfectly valid alternative), we should remove this PR description requirement for everybody. That works too. > What if there is no cover letter in the patch set in patch #0 summary? That's generally (not always though!) a bad sign in itself. Either the cover letter of the patch set, or the bugzilla report, should contain a good, relatively high-level description of the issue (or feature), and the changes implemented to address it. At this point, *that* description should be copied into the PR. If *neither* the BZ ticket *nor* the patch series cover letter contains this kind of summary / overview, then *that* is a big problem, and should be remedied. > For the patch I merged, > I am still not very sure what info I should put there. The cover letter [edk2-devel] [PATCH v5 0/3] UefiPayloadPkg: Runtime MMCONF seems to say that the patch set adds support for "arbitrary platforms with different or even no MMCONF space" to UefiPayloadPkg. Additionally, it fixes a crash on platforms not exposing 256 buses. That's the info. > > I don't know why Laszlo mentioned BZ for my merge since there is no BZ > mentioned in the patchset. I finished with the following paragraph: "(Please note also that I absolutely don't need a BZ for every contribution. My request is only that *if* there is a BZ, then handle it thoroughly.)" I discussed BZs in general. > And I also don't know why Laszlo mentioned to send email after the > patch is merged since I don't find this requirement in the development > process. How else is a contributor supposed learn of their patch series being merged? Are they supposed to pull the master twice daily, and hope that their patches show up eventually? I mean, the patches you merge originate from the list. Where else is the best place to report back to the submitter (and to the rest of the community) than under the original patch thread? > I don't think it is doable to ask all the maintainers to monitor EDK2 > mail list on how others are doing since there are so many emails every > day, especially there is no any patch for UefiPayloadPkg for several > months. I strongly disagree. If you are listed as a maintainer, that implies you *care* what happens in the community. If you don't (or cannot) care about workflow, then the "M" role is not a good fit for you. > I hope we could simplify the process and have a clear steps in the > process soon. So that the maintainers could focus on the actual code > review. Please see "Maintainers.txt": M: Package Maintainer: Cc address for patches and questions. Responsible for reviewing and pushing package changes to source control. If you are a Maintainer, that means you are responsible for pushing changes, and for parts of the workflow that come with that. It's a service to the community. If you don't care about that, then the "R" role is more appropriate: R: Package Reviewer: Cc address for patches and questions. Reviewers help maintainers review code, but don't have push access. A designated Package Reviewer is reasonably familiar with the Package (or some modules thereof), and/or provides testing or regression testing for the Package (or some modules thereof), in certain platforms and environments. Thanks Laszlo