Hi Phil, I am curious why the GIT committer information is so important.
Before CI, for any given package, the committer can be the primary maintainer, the backup maintainer, or a steward. The maintainer that actually does the commit is following the process and the rules for doing a push, but may not have been involved in the code change, reviews, or testing. To me, the critical information is the Author, Reviewed-by, Acked-by, and Tested-by tags, which I believe are all correct when Mergify bot does the commit. What is the use case I am missing here? Thanks, Mike > -----Original Message----- > From: devel@edk2.groups.io <devel@edk2.groups.io> On > Behalf Of Philippe Mathieu-Daudé > Sent: Thursday, January 2, 2020 6:42 AM > To: devel@edk2.groups.io; Kinney, Michael D > <michael.d.kin...@intel.com>; Sean Brogan > <sean.bro...@microsoft.com>; Bret Barkelew > <bret.barke...@microsoft.com>; Gao, Liming > <liming....@intel.com> > Cc: Laszlo Ersek <ler...@redhat.com> > Subject: Re: [edk2-devel] EDK II Maintainers - EDK II > CI is now active on edk2/master > > Hi Michael, > > On 11/12/19 3:55 AM, Michael D Kinney wrote: > > EDK II Maintainers, > > > > EDK II CI Phase 1 feature is now active on > edk2/master. > > > > Please use a GitHub pull request from a branch in a > personal > > fork of the edk2 repository with a 'push' label to > request > > a set of patches to be pushed to edk2/master. The > GitHub PR > > replaces the 'git push' operation currently used to > commit > > changes to edk2/master. > > > > You will need to configure your notifications from > the edk2 > > repository to make sure you receive email > notifications > > when the checks against the GitHub PR passes or > fails. > > > > If you submit a GitHub Pull Request without the > 'push' > > label, then the CI checks are run and the results are > > generated. > > > > Please let us know if there are any questions about > this > > change in the development process. > > I have 2 requests: > > 1/ Is it possible to have the Mergify bot use the merge > request author > name/email as GIT_COMMITTER_[NAME/EMAIL] instead of > throwing away this > information from the git history? > > Before we could directly use this information to email > the maintainer > who merged the patch in. > Currently I can't find an easy way... I've to dig thru > the mailing list > archives for the last thread, figure out who could have > merge this, > check the different maintainers GitHub repository... > > The new way might be using this filter (which is not > listed by default): > https://github.com/tianocore/edk2/pulls?utf8=%E2%9C%93&; > q=is%3Apr+is%3Amerged > > Then go thru the last ones, but this doesn't scale in > few months to look > at old merges. > > 2/ Can the Mergify bot send a mail to the list to > notify a patch got merged? > > For example going thru my backlog I was going to review > this series: > https://edk2.groups.io/g/devel/message/52613 > But it is already merged... The series subject is > "Microcode related > optimizations" and when I searched for it first with > the GitHub MR > filter from 1/, I couldn't find it. Later I figured it > got merged with > another subject "Mpinitlib opt push 1". > > One way to simplify Mergify to send email, is to ask > maintainers to put > the series cover (or each patches) URL in the GitHub > merge request > description, or the email Message ID(s). Since we are > switching the a > mostly HTTP workflow, using URLs is probably > recommended. > > Thanks, and happy new year! :) > > Phil. > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#52665): https://edk2.groups.io/g/devel/message/52665 Mute This Topic: https://groups.io/mt/53725670/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
