public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "gaoliming" <gaoliming@byosoft.com.cn>
To: <devel@edk2.groups.io>, <lersek@redhat.com>,
	"'Dong, Guo'" <guo.dong@intel.com>
Cc: <marcello.bauer@9elements.com>,
	"'Kinney, Michael D'" <michael.d.kinney@intel.com>,
	"'Leif Lindholm \(Nuvia address\)'" <leif@nuviainc.com>,
	"'Doran, Mark'" <mark.doran@intel.com>,
	"'Andrew Fish'" <afish@apple.com>,
	"'Guptha, Soumya K'" <soumya.k.guptha@intel.com>
Subject: 回复: [edk2-devel] more development process failure [was: UefiPayloadPkg: Runtime MMCONF]
Date: Thu, 17 Sep 2020 09:49:08 +0800	[thread overview]
Message-ID: <000e01d68c94$bb92d920$32b88b60$@byosoft.com.cn> (raw)
In-Reply-To: <cc68848e-c4fc-37e9-57a5-d62c6a9087cc@redhat.com>

Guo:
On pull request, https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process#the-maintainer-process-for-the-edk-ii-project section 7 gives the requirement. 
If <new-integration-branch> is a patch series, then copy the patch #0 summary into the pull request description.

Laszlo:
I think we can enhance wiki page https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process#the-maintainer-process-for-the-edk-ii-project to add another step to reply the patch mail with the merged pull request or commit after PR is merged. 

Thanks
Liming
> -----邮件原件-----
> 发件人: bounce+27952+65339+4905953+8761045@groups.io
> <bounce+27952+65339+4905953+8761045@groups.io> 代表 Laszlo Ersek
> 发送时间: 2020年9月17日 2:14
> 收件人: Dong, Guo <guo.dong@intel.com>; devel@edk2.groups.io
> 抄送: marcello.bauer@9elements.com; Kinney, Michael D
> <michael.d.kinney@intel.com>; Leif Lindholm (Nuvia address)
> <leif@nuviainc.com>; Doran, Mark <mark.doran@intel.com>; Andrew Fish
> <afish@apple.com>; Guptha, Soumya K <soumya.k.guptha@intel.com>
> 主题: Re: [edk2-devel] more development process failure [was:
> UefiPayloadPkg: Runtime MMCONF]
> 
> On 09/16/20 19:30, Dong, Guo wrote:
> >
> > Hi Laszlo,
> >
> > The patchset includes 3 patches, and all of them had been reviewed by
> package owners.
> > The patch submitter has a pull request
> https://github.com/tianocore/edk2/pull/885, I rebased the patch to latest
> master, and merged it by adding reviewed-by found from emails.
> > I also make sure it passed all the checks before I put "push" button there.
> then retrigger a new build with "push" button.
> >
> > I am not sure what is missing. If there is any other requirements, should
> they be captured during code review or tool check?
> 
> - The description field of <https://github.com/tianocore/edk2/pull/932/>
> is empty. It's difficult to tell where the patches come from -- where
> they were posted and reviewed. A copy of the cover letter should have
> been included here, plus preferably a link to the v5 mailing list thread
> (the one that got merged in the end).
> 
> - It was not confirmed in the v5 mailing list thread that the series had
> been merged. The confirmation should have included at least one of: (a)
> the github PR link, (b) the git commit range. (Preferably: both.)
> 
> It's not the eventual git commits that I'm complaining about, but the
> lack of communication with the community, and the lack of record for
> posterity.
> 
> Myself, I used to consider github PRs a means merely for replacing our
> earlier direct "git push" commands -- with a CI build + mergify. So, as
> a maintainer, I would myself queue up several patch sets in a single
> "batch" PR, add some links to BZs and the mailing list, and let it fly.
> But then Mike told me this was really wrong, and we should clearly
> associate any given PR with a specific patch set on the list.
> 
> This meant an *immense* workload increase for me, in particular because
> I tend to merge patch sets for *other* people and subsystems too (after
> they pass review), that is, for such subsystems that I do not
> co-maintain. In particular during the feature freeze periods.
> 
> So what really rubs me the wrong way is that, if I am expected to keep
> all of this meta-data nice and tidy, why aren't some other maintainers?
> It's a double standard.
> 
> I can live with either *all of us* ignoring PR tidiness, or *all of us*
> doing our best to keep everything nicely cross-referenced.
> 
> But right now I spend significant time and effort on keeping
> communication and records complete and clean in *all three of* bugzilla,
> github, and mailing list, whereas a good subset of the maintainers
> couldn't care less in *either* of those communication channels.
> 
> For your reference, here's a random PR I submitted and merged for others:
> 
>   https://github.com/tianocore/edk2/pull/904
> 
> Observe in PR#904:
> 
> - title carries cover letter subject
> - description carries cover letter body
> - description has a pointer to the BZ, and a link to the cover letter in
> the mailing list archive (two links in fact, in different archives)
> 
> And then here's my report back on the list:
> 
>   https://edk2.groups.io/g/devel/message/64644
> 
> And my BZ comment to the same effect (also closing the BZ as
> RESOLVED|FIXED):
> 
>   https://bugzilla.tianocore.org/show_bug.cgi?id=2376#c9
>   https://edk2.groups.io/g/bugs/message/12777
> 
> 
> I don't insist on the particular information content of github PRs, as
> -- at this stage -- they really are not more than just a way to set off
> CI, before pushing/merging a series.
> 
> What I do insist on is that all of us maintainers (people with
> permission to set the "push" label) be subject to the same expectations
> when it comes to creating pull requests.
> 
> (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.)
> 
> Laszlo
> 
> 
> >
> > Thanks,
> > Guo
> >
> >> -----Original Message-----
> >> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
> >> Ersek
> >> Sent: Wednesday, September 16, 2020 1:57 AM
> >> To: Dong, Guo <guo.dong@intel.com>
> >> Cc: devel@edk2.groups.io; marcello.bauer@9elements.com; Kinney,
> Michael D
> >> <michael.d.kinney@intel.com>; Leif Lindholm (Nuvia address)
> >> <leif@nuviainc.com>; Doran, Mark <mark.doran@intel.com>; Andrew Fish
> >> <afish@apple.com>; Guptha, Soumya K <soumya.k.guptha@intel.com>
> >> Subject: [edk2-devel] more development process failure [was:
> UefiPayloadPkg:
> >> Runtime MMCONF]
> >>
> >> Guo,
> >>
> >> On 08/18/20 10:24, Marcello Sylvester Bauer wrote:
> >>> Support arbitrary platforms with different or even no MMCONF space.
> >>> Fixes crash on platforms not exposing 256 buses.
> >>>
> >>> Tested on:
> >>> * AMD Stoney Ridge
> >>>
> >>> Branch: https://github.com/9elements/edk2-1/tree/UefiPayloadPkg-
> >> MMCONF
> >>> PR: https://github.com/tianocore/edk2/pull/885
> >>>
> >>> v5:
> >>> * MdePkg
> >>>   - support variable size MMCONF in all PciExpressLibs
> >>>   - use (UINTX)-1 as return values for invalid Pci addresses
> >>
> >> Okay, so we got more of the same development process violations here, as
> >> I've just reported at <https://edk2.groups.io/g/devel/message/65313>.
> >>
> >> See this new pull request:
> >>
> >>   https://github.com/tianocore/edk2/pull/932/
> >>
> >> "No description provided."
> >>
> >> You should be embarrassed.
> >>
> >> Laszlo
> >>
> >>
> >>
> >>
> >>
> >
> 
> 
> 
> 
> 




  parent reply	other threads:[~2020-09-17  1:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18  8:24 [PATCH v5 0/3] UefiPayloadPkg: Runtime MMCONF Marcello Sylvester Bauer
2020-08-18  8:24 ` [PATCH v5 1/3] UefiPayloadPkg: Store the size of the MMCONF window Marcello Sylvester Bauer
2020-08-18  8:24 ` [PATCH v5 2/3] MdePkg: PciExpressLib support variable size MMCONF Marcello Sylvester Bauer
2020-08-20 10:55   ` Liming Gao
2020-08-18  8:24 ` [PATCH v5 3/3] UefiPayloadPkg: Support variable size MMCONF space Marcello Sylvester Bauer
2020-09-08 22:35   ` [edk2-devel] " Guo Dong
2020-09-16  8:56 ` more development process failure [was: UefiPayloadPkg: Runtime MMCONF] Laszlo Ersek
2020-09-16 17:30   ` [edk2-devel] " Guo Dong
2020-09-16 18:14     ` Laszlo Ersek
2020-09-16 21:51       ` Guo Dong
2020-09-17  5:59         ` Laszlo Ersek
2020-09-17  1:49       ` gaoliming [this message]
2020-09-17  2:31         ` Yao, Jiewen
2020-09-17  6:31           ` Laszlo Ersek
2020-09-17  7:31             ` Yao, Jiewen
2020-09-17 10:26               ` Laszlo Ersek
2020-09-18  4:39             ` Ni, Ray
2020-09-18  7:37               ` Andrew Fish
2020-09-26  0:34                 ` Guo Dong
2020-09-27  1:44                   ` 回复: " gaoliming
2020-09-27 17:29                     ` Guo Dong
2020-09-28 17:55                   ` Laszlo Ersek
2020-09-29  4:13                     ` Guo Dong
2020-09-29 11:59                       ` Laszlo Ersek
2020-09-17  5:56         ` 回复: " Laszlo Ersek
2020-09-21  9:57   ` Marcello Sylvester Bauer
2020-09-22  6:45     ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000e01d68c94$bb92d920$32b88b60$@byosoft.com.cn' \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox