On Sat, Aug 1, 2020 at 03:47 PM, Laszlo Ersek wrote:

On 08/01/20 00:19, Artem Shchygel wrote: > Hi, All > > In this RFC we're proposing slight changes to Git commit message format to make it more informative and more friendly for automation tools. > > Here is the list of changes proposed > > 1. Start subject line with the tag that describes nature of the commit. List of tags is as follows: > - fix: For commits that are fixing the bug > - feat: For commits that introduce a new feature > - imp: For commits that introduce improvement of the existing code logic without changing functionality > - doc: For commits that don't change code logic but deal with documentation (including adding comments, fix spelling, etc.) > - style: For commits that don't change code logic but deal with coding style (indents, whitespaces, etc.) > - chore: For commits that don't affect output target (like changes to CI scripts) > Having tagged commits will help closed source maintainers to decide which commits to cherry-pick for projects that are in "maintenance mode" as opposite to "active development mode"

Hints are very welcome, but not in subject lines. Please use

Name: value Name: value # comment

style tags near the end of the commit messages instead.

Here are the reasons I believe subject line tags should be in subject line: 1. It is expected for those tags to be mandatory. This requirement will force committer to think one more time about what commit changes are about. This may (hopefully) lead to more structured commits, where fixes, improvements, features and style changes are not mixed together. But when you try to make something mandatory it's better to minimize the friction/cognitive load for actually doing the thing. From this point of view short tag in subject line is easier to add than separate line with "Name: value" in the commit body, which for trivial changes may even not be there. 2. I believe these tags, while certainly be machine-friendly still have some human-readable value. For example we can easily say that commits marked as doc/style/chore have no regression impact even if the commit itself is pretty large. We can also assume that "fix" commits will be smaller and easier to merge/backport than "feat" or "imp" commits. > > Subject lines are primarily for human readers. And because edk2 has long > filenames, and we're supposed to include package names and component > names in subject lines, hardly any space is left for actual meaningful > subjects. CVE identifiers are the only exceptions (they should be > mentioned in subjects lines; and PatchCheck.py already permits more > characters in subjects that contain CVE identifiers). > > > 2. Remove "Package/Module" reference from subject line. Since subject line > length is limited it's better to be allocated for commit description which is > more important > > I'm opposed to this. "Package/Module" is the absolute key by which I > orient myself for determining impact / maintainership relevance / > regression risk. I regularly browse the git history for new commits, and > I entirely orient myself after the Package/Module prefixes.

As you've said above adding "Package/Module" description leave almost no space for meaningful subjects, practically rendering them useless. Add to that the fact that this information is redundant in the sense, that it's already included in changed files paths. Now I'm obviously don't know actual workflow maintainers use to perform their tasks, so it's hard to come up with replacements. But filtering commits changing files in folders of the particular interest can be easily done with git log command if you work with actual repo. If you look for particular folders in email inbox I think there is the way to have email subject include "Package/Module" reference, while not having it in the commit subject line > > > 3. Remove "CVE" number from subject line for the same reason. CVE number (if > present) should be placed on separate line after long description (see example > below) > > I agree that mentioning CVE IDs in subject lines is an exceptions. I > could let go of that, if contributors were very disciplined about > stating CVE IDs properly in commit messages. >

I think including CVE reference (which you probably can't easily type right off your head, but have to look it up) takes the same amount of discipline regardless of whether it's included in the subject line or on the separate line in commit's body > > 4. Add optional tag to the long description. List of tags is as follows: > > - [BREAKING CHANGE]: For commits that break backward compatibility > > - [SECURITY FIX]: For commits that fix known security vulnerability > > Explicitly stating such traits is very welcome (even if not with this > specific format, perhaps) in commit message bodies.

The format of optional tag is flexible, any suggestions are welcome > > > > 5. Move bugzilla reference to separate line after long description and > (possible) CVE line (see example below). This move follows the logic of > evaluation of commit nature (read subject, if unclear read long description, > if still unclear see bugzilla) > > Bugzilla numbers should already be stated as: > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 > > or > > Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 > > or > > Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2129 > > tags. >

We're not proposing format changes for bugzilla references, just their placement in the commit body. Instead of being in first lines we propose to move them to the last lines > > > > > An example would be: > > > > imp: Short one line description of change > > > > Several lines of > > description for the > > change. > > > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1000 > > > > Signed-off-by: Contributor Name <contributor@...> > > Reviewed-by: Reviewer Name <reviewer@...> > > > > > > A CVE example would be: > > > > fix: Short one line description of change > > > > [SECURITY FIX]: Several lines of > > description for the > > change. > > > > CVE-2018-12180 > > > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2000 > > > > Signed-off-by: Contributor Name <contributor@...> > > Reviewed-by: Reviewer Name <reviewer@...> > > > > I entirely support including as much information as possible in commit > messages; if we can do that in machine readable format, that's even > better. But subject lines are not the place; the commit message bodies are. > > I recommend the "Name: value" and "Name: value # comment" formats, but > don't insist on those. > > What really matters to me is that we don't litter subject lines with > machine-readable artifacts. > > Obviously: this is just my personal opinion. > > Thanks > Laszlo

Thank you for taking your time to review our proposal. Your comments allowed me to express our intentions more clearly

Artem > >