Is your feature request related to a problem? Please describe.
When applying software updates, good practice requires a system administrator to review proposed updates and confirm their suitability for any given system; and to review them so as to help triage any issues (such as those caused by regression) that may be encountered post update.
For updates to the Linux Kernel in particular (although this does apply to other complex packages) the ability of even an experienced SA to review the Changelog in Mint Update Manager and make sense of what has been revised (say down to a subsystem level of resolution) is effectively impossible. Here is a small extract from a kernel changelog file as an illustrated example:-
[Packaging] resync debian/dkms-versions from main package
-- Stefan Bader stefan.bader@canonical.com Fri, 28 Jan 2022 15:35:28 +0100
linux-meta-hwe-5.13 (5.13.0.28.31~20.04.15) focal; urgency=medium
Packaging resync (LP: #1786013)
[Packaging] update variants
-- Stefan Bader stefan.bader@canonical.com Thu, 20 Jan 2022 14:51:59 +0100
linux-meta-hwe-5.13 (5.13.0.28.31~20.04.14) focal; urgency=medium
Describe the solution you'd like
In a perfect world, each kernel update shipped via Update Manager would come with a "Business English" description of the changes being introduced, distilled and summarised from the detailed line items. Perhaps it is possible to do this in the context of the kernel diagram:-
https://makelinux.github.io/kernel/diagram/
For example by using the names of the elements described in the above link illustration to provide a summary of impacted changes.
Or perhaps it is possible to be even more terse and just use simple descriptions to identify areas where the code has changed:
"USB", or "NFS" or "Network Interface and Drviers" or similar.
In particular, it would be helpful if the update contained a clearer summary to help an average user or SA to determine whether a kernel update were a priority (for example to fix a kernel bug that exposes a security issue) as opposed to one which adds new functionality or new hardware support.
Describe alternatives you've considered
In the context of this suggestion I would imagine that the only viable alternative would be to automate this via some kind of parsing code that is able to compare either source or compiled binaries and use some form of "local knowledge" of the relationship between the code that is detected as changed and the functionality provided to give a summary of potential impact.
Additional context
I do appreciate that the Mint Team take kernels prepared by Canonical and/or Debian for inclusion with distro images and are therefore not directly responsible for this. And of course kernel changes come via Linus, GKH et al. But the value of having something like this would be to help with the triage of post-uprgrade issues and to provide more useful feedback to package maintainers when problems are encountered.
We've all seen, "Application crashes. Please help!" user reports... Hopefully this approach or a variation on it might be able to get more useful information to a triage team. It would certainly help SA's to decide whether or not a kernel upgrade should be applied.
I don't underestimate how much additional work this may require (if not automated), but I do think it would add significant value to downstream users.
Is your feature request related to a problem? Please describe. When applying software updates, good practice requires a system administrator to review proposed updates and confirm their suitability for any given system; and to review them so as to help triage any issues (such as those caused by regression) that may be encountered post update.
For updates to the Linux Kernel in particular (although this does apply to other complex packages) the ability of even an experienced SA to review the Changelog in Mint Update Manager and make sense of what has been revised (say down to a subsystem level of resolution) is effectively impossible. Here is a small extract from a kernel changelog file as an illustrated example:-
_linux-meta-hwe-5.13 (5.13.0.29.32~20.04.16) focal; urgency=medium
Describe the solution you'd like In a perfect world, each kernel update shipped via Update Manager would come with a "Business English" description of the changes being introduced, distilled and summarised from the detailed line items. Perhaps it is possible to do this in the context of the kernel diagram:- https://makelinux.github.io/kernel/diagram/
For example by using the names of the elements described in the above link illustration to provide a summary of impacted changes.
Or perhaps it is possible to be even more terse and just use simple descriptions to identify areas where the code has changed:
"USB", or "NFS" or "Network Interface and Drviers" or similar.
In particular, it would be helpful if the update contained a clearer summary to help an average user or SA to determine whether a kernel update were a priority (for example to fix a kernel bug that exposes a security issue) as opposed to one which adds new functionality or new hardware support.
Describe alternatives you've considered In the context of this suggestion I would imagine that the only viable alternative would be to automate this via some kind of parsing code that is able to compare either source or compiled binaries and use some form of "local knowledge" of the relationship between the code that is detected as changed and the functionality provided to give a summary of potential impact.
Additional context I do appreciate that the Mint Team take kernels prepared by Canonical and/or Debian for inclusion with distro images and are therefore not directly responsible for this. And of course kernel changes come via Linus, GKH et al. But the value of having something like this would be to help with the triage of post-uprgrade issues and to provide more useful feedback to package maintainers when problems are encountered.
We've all seen, "Application crashes. Please help!" user reports... Hopefully this approach or a variation on it might be able to get more useful information to a triage team. It would certainly help SA's to decide whether or not a kernel upgrade should be applied.
I don't underestimate how much additional work this may require (if not automated), but I do think it would add significant value to downstream users.