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

["Laszlo Ersek" <lersek@redhat.com>]

On 01/02/20 15:42, Philippe Mathieu-Daudé wrote:

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

I noticed that too, but I thought that having a robot rather than a
human in the committer meta-datum was tolerable. (Not great, but
acceptable.)

The authorship meta-datum is still correct, to my understanding. If
there's a problem later with a commit, I'd probably email the author (CC
list), not the committer.

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

Including the cover letter contents and/or mailing list reference in the
PR description is already recommended practice, to my understanding. The
related tianocore BZ should be noted in the PR description too. AIUI,
it's also recommended to name the PR in accordance with the series cover
letter's subject line. Unfortunately, maintainers don't seem to be
following these recommendations.

Regarding an email notification about a merge, I have two comments:

- Personally, I always follow up with a manual message to the list, once
a series is merged, pointing out the new commit range. It's not a huge
burden.

- Github generates emails about PR actions. Unfortunately, the current
scheme for a merge ("Merged #263 into master") is really lacking. It
cannot be easily filtered for (you have to check the message body to see
it's a "merge"), plus the resultant commit range (-> master branch
advance) is not communicated. I don't know if this would be best
remedied in the general github.com website code, or in the mergify bot code.

No tooling will ever provide enough information for the community so
long as maintainers are unwilling to spend time on administrative
actions. The attraction of github.com for the grand public is not that
github.com implements these administrative actions itself, un-burdening
developers; instead, the attraction is that github.com pretends these
actions are not important at all, and so nobody should care about them.
You can't really make a tool care if maintainers don't care.

Thanks
Laszlo