RFE: tools: generate release notes

[dougsland]

Developers, PMs, Docs Teams, etc must be able to generate release notes between two tags without GitHub UI or contact QM maintainers to avoid their work be blocked.

cc @pbrilla-rh @mwperina @Yarboa @kleinffm

[kleinffm]

Thanks for your efforts to make release note generation more efficient, @dougsland!

While I can see that this tool fetches and diffs the commit log tags and pulls them into the section categories the way we have been temporarily handling the grouped upstream backports we've been doing for BlueChi, the standard release notes generation workflow and toolset we use parses the categories by the Release Note Type field in Jira.

That said, I'm not sure I understand how this tool you've proposed operates with the tool that we already use aCoRNs to pull all Release Note Type and Release Note Text field values from Jira for a particular release to populate an asciidoc file that we can publish to one or more output formats (e.g., PDF, HTML).

If this tool pulls the tags from the upstream repo for a release and diffs it against the prior release, and generates the data the release note to populate the Jira fields, this could be a good tool to expedite the data gathering from the upstream sources. Each of the release note categories would need to update the Release Note Type field on the correlated Jira ticket. I suppose the tag text would be what you intend to pull into the Release Note Text field. However, since tag or commit text generally only describes the change, engineers and writers would still need to collaborate on the text for the causes, consequences, reasons, results, workarounds (for temporary fixes), or replacements (for discontinued workaround fixes or features) to add context to each release note for users.

Let me know if you have questions about this feedback.

[dougsland]

Hi Felicia,

Thanks for your efforts to make release note generation more efficient, @dougsland!

thank you

While I can see that this tool fetches and diffs the commit log tags and pulls them into the section categories the way we have been temporarily handling the grouped upstream backports we've been doing for BlueChi, the standard release notes generation workflow and toolset we use parses the categories by the Release Note Type field in Jira.

Oh okay, it's temporary process. My original idea was "avoid people get blocked while I am working in different bits". However, if the process will change, the tool will need to be adjusted too.

That said, I'm not sure I understand how this tool you've proposed operates with the tool that we already use aCoRNs to pull all Release Note Type and Release Note Text field values from Jira for a particular release to populate an asciidoc file that we can publish to one or more output formats (e.g., PDF, HTML).

Not integrated to acorns today, only works as you described below.

If this tool pulls the tags from the upstream repo for a release and diffs it against the prior release, and generates the data the release note to populate the Jira fields, this could be a good tool to expedite the data gathering from the upstream sources. Each of the release note categories would need to update the Release Note Type field on the correlated Jira ticket.

This is what we do today (again, I understood this was enough to have the flow moved and do not get blocked on me). However, looks like we need additional steps that we can discuss to improve the tool. Let's setup a 1x1.

I suppose the tag text would be what you intend to pull into the Release Note Text field. However, since tag or commit text generally only describes the change, engineers and writers would still need to collaborate on the text for the causes, consequences, reasons, results, workarounds (for temporary fixes), or replacements (for discontinued workaround fixes or features) to add context to each release note for users.

For this part there is no automation, still will need engineers collaborating. :)

[dougsland]

@kleinffm I will merge what we have now but I will setup 1x1 too so we can continue there.