Proposals for commit log policy

[Alexander Amelkin]

22.08.2018 23:39, Tanous, Ed wrote:
> I'm not really understanding the issue here.  Is the log information not available in the individual repositories?  Is it just hard to parse?  Could this be automated, either using a script, or a list of repositories?
You're obviously not getting my point. There are logs. But they are purely developer-oriented. Nobody actually cares (except for developers) that, for instance, some commit "Resolves some build failures and updates the bmcweb recipe to use the proper target names for image selection". That change is TOTALLY invisible to end users and must not get into Release Notes for a binary firmware release. Nobody actually wants to know that some changeset "replaces phosphor rest with bmcweb for the s2600wf target" or that "the handcoded harware sensor yaml file is merged with the final sensor yaml file". What end users want to know before they make a decision to upgrade is how the system behavior (user experience, responses to commands, etc.) has changed since the currently installed firmware. Writing end-user-centric Release Notes for a binary release takes a lot of time, because it requires analyzing all those purely developer-oriented logs. And that's a job that is done on a regular
basis by each vendor, I believe. And it takes, as I said, at least 3 full days contiguously of a qualified engineer. What I propose is ask each engineer who commits a change and knows his change, thus doesn't need to spend time analyzing it, to write a short description of end user impact. It will take like 5 extra minutes per commit.

> While I think there's value in the logs, I don't think maintainers time is best used by creating git logs manually all the time, especially when it should be easy enough to parse the git logs between the recipe bumps.  I've had to do this before to do bisects before, and it's not too difficult once you get the hang of 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. But the end user impact information is not. It's either written by the developer in the commit log, or deduced (sometimes incorrectly or incompletely) by an engineer writing the Release Notes.

Alexander.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180823/c511cb43/attachment.sig>