Proposals for commit log policy

[Tanous, Ed]

Do you have an example of the version to version logs that are the result of the "3 full days contiguously of a qualified engineer" that you're asking the community to help you create?  I suspect if they were published (forgive me if they already are and I've just missed them) back to the project somewhere, and people found value, it might help the value proposition for developers a lot more.  Right now I'm seeing that is would be a lot of work on the part of code reviews, for only a minor gain.  This is coming from someone who has written release notes a lot.  I find the most value in release notes to be a consistent tone, language, and filtering, with a level of abstraction that is high enough to be useful.  I'd be surprised if we were able to get that kind of consistency from all the people on the project of varying backgrounds.

Another thing to consider is that there are a lot of non-native English speakers in the community, and while I would love it if everyone had a perfect grasp of the English language, I would _much_ rather that they know how to design, build, and test embedded firmware, while leaving the documentation to the people that excel at it.


> For bumps the task is "automatable" indeed. It's not actually as easy with
> Yocto as it may seem "to parse the git logs between the recipe bumps" (have
> you tried?), but it can be automated.

We don't dump the git logs, but my team does track the SHAs of the openbmc components in each revision we build for audit and reproducibility needs.  It's possible I'm missing something here, but it feels like dumping the logs would be a minor addition to the <20 line python script.  Our existing one just searches a glob of *.bb and *.bbappend files, greps for SHA1 changes, and fetches the relevant repos.  When I get a moment, I'll take a look and see if it can be easily generalized to dump logs for you if that helps some.

-Ed