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
> >>
> >>
> >>
> >>
> >>
> >
>
>
>
>
>
next prev 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