Release notes process

There’s need to generate release notes for each release and the process should be automated or at least described in some way.

After thinking a bit I came up with following idea:

Each developer/(project member) can nominate any issue to be included into release notes.
To do so they (or product manager/other project member) assign scoped label to the issue (like release_notes::candidate)

Optional: Automation/CI/script goes to each such issue and post information request there with the template to be filled in and changes scope to release_notes::input_needed . This step will save Dev’s time on looking into documentation for this template

Once developer see this label they put information needed into comment using template and change scope to release_notes::ready

Automation/CI/script/release engineer uses provided information to generate release notes entry from it. ( Or put gentle reminders if the release is approaching but information was not provided )

This should allow to save time before the release itself and spread documentation phase across whole development cycle.

Template itself TBD but it should not take more than 5 minutes to fill it in.

The process can be easily scaled to generate other release-related documentation (known issues, fixed bugs etc)

Thoughts?

@landgraf How long would writing such a tool to request a template to be filled and then parse the filled out information take?

Do you want to roll this out for Jasmine or assign the scoped labels manually this time around with help from @SebS @Adam_Szpilko and @rzr ?

I like the idea of automating this for Jasmine+1 definitely.

Asking for input is easy and the code is written already (gitlab-python). Parsing is in progress. I expect it to be ready this week (basically today). Templates, output format and so should be discussed.

See example rn generated: Sign in · GitLab CC: @idlethread @Stefan_Schmidt @davidinux

I like the flow based on issues and also asking developers to write user-readable description.

What seems to be missing is the current version is the list of closed CVEs. They might, but not have to, correspond to the bug records. They might also, at the time of the release, might be still unpublished. I think we can do with another set of tickets (public tickets) that might be linked to the actual issue ticket when the issue gets public.

CVE process is different task iirc. Can we parse output of cve-checker at the point of release-1 and releaseN to create such list? The logic is quite complicated taking into account number of images and flavours though.

For the CVEs from upstreams, yes we can do something like that. Merge all the CVE logs & do a compare between releases. This will show only the public CVEs, not the embargoed ones (as cve-checker won’t show them - but it will show those that were published between two releases).

That leaves the security issues reported to us (i.e. our security bugtracker). This is something we could handle in a similar way to regular bugs and list CVEs if there are some without more information. This should be quite simple to do.