Re: [edk2-devel] EDK II Maintainers - EDK II CI is now active on edk2/master

["Michael D Kinney" <michael.d.kinney@intel.com>]

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.kinney@intel.com>; Sean Brogan
> <sean.brogan@microsoft.com>; Bret Barkelew
> <Bret.Barkelew@microsoft.com>; Gao, Liming
> <liming.gao@intel.com>
> Cc: Laszlo Ersek <lersek@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.
> 
> 
>