> 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. > From the EDK II Development Process Mike edited, there is no such requirement to add description for the patches that have no BZ. I think you should ask Mike to update the process so that every Maintainer could follow the same steps if Mike ever asked you to do it. It doesn't make sense to blame others using this kind of "hidden rule" if it is "really" required. > 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? > As I replied to Liming, the EDK II Development Process mentioned this " Email notifications for pull requests, pushes, and check status results are enabled by watching the EDK II repository (https://github.com/ tianocore/edk2). " So that you could get email notification if these status if you want. Again, you had better ask Mike to add this step in the process if you think it is required.
> > 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 don't think we have requirements to ask maintainers to read all EDK2 emails or know all the things in the community from EDK II Development Process or from Maintainers.txt. Not sure where you get it. From my view point, the package "M" only need *care* the package they maintained following the "M" role defined by the EDK2 documents. It is good to care other packages if having time, but there is no such requirement. > > 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. > That's what I am doing now to review and merge the patch following these edk2 defined requirements. > Thanks > Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#65707): https://edk2.groups.io/g/devel/message/65707 Mute This Topic: https://groups.io/mt/76902353/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
