How to reorganize the changelog list to be more readable?

[BigFreddy]

Hi,

Does anyone know if you can reorganize the changelog list you get during the updates and upgrades to be more readable either natively or via some sort of plugin? Most changelog entries appear to be for developers and I'm only interested in security and changes that can break my setup, changelogs like:

interfaces: provide "uuid" in legacy_config_get_interfaces()

or

o src: bind: lookup local address in current FIB if '*.bind_all_fibs' is active

or

o src: net: add fib-aware ifa_ifwithaddr()

Don't tell me much and seems to be more directed for developers or people who contribute into the codebase of the firewall.

Thanks

[franco]

You can look up the commit, or we can omit them. I don't think omitting adds value, especially if regressions occur.

If it doesn't sound interesting it's probably just that.


Cheers,
Franco

[BigFreddy]

You can look up the commit, or we can omit them. I don't think omitting adds value, especially if regressions occur.

If it doesn't sound interesting it's probably just that.


Cheers,
Franco

What I had in mind when I was making this post was that it would be a good idea to divide the changelog into more readable sections, in my mind, these three would make more sense: Security, Breaking Changes, Developer Notes then under them, list the changelogs that apply per each section.

[nero355]

Security

Security is basically always at the bottom if you want to know the complete story behind the reason why the patch was applied to certain modules/software/etc. :)

[franco]

What I had in mind when I was making this post was that it would be a good idea to divide the changelog into more readable sections, in my mind, these three would make more sense: Security, Breaking Changes, Developer Notes then under them, list the changelogs that apply per each section.

I can see the value, but, traditionally, journalism was a way for digested information to be readily available in the past. There's not a lot of tech journalism still around and interested in networking projects. And we don't want to spend too much time doing blog-post analysis of things that are going on which few people will read no matter how good it is written.

We also can't stop publishing the release notes in the format we have because the development digest has the biggest value for looking for regressions.  Breaking changes are only really intended for major upgrades and are listed as "migration notes". Security issues vary wildly in scope.  You'll have links to most security issues.  Things may change on the front, but there are no concrete plans yet.


Cheers,
Franco