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

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 1/2/20 7:36 PM, Kinney, Michael D wrote:
> 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.

Yes, they are correct.

> 
> What is the use case I am missing here?

I guess I'm probably too rigid, custom to process all merge information 
in my gitk window.
If one day I've too look at Mergify I'll see if it is possible to 
properly set the GIT_COMMITTER_[NAME/EMAIL] env vars before merging.

Sorry for the noise,

Phil.

>> -----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.
>>
>>
>> 
>