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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#52826): https://edk2.groups.io/g/devel/message/52826 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] -=-=-=-=-=-=-=-=-=-=-=-
