Comment 2 for bug 1616020

Thanks for your feedback. I think that the situation is covered by 2.2 of the SRU document:

> For Long Term Support releases we regularly want to enable new hardware. Such changes are
> appropriate provided that we can ensure not to affect upgrades on existing hardware. For
> example, modaliases of newly introduced drivers must not overlap with previously shipped
> drivers. This also includes updating hardware description data such as udev's keymaps,
> media-player-info, mobile broadband vendors, or PCI vendor/product list updates.

On the other hand, the hardware works well even without the new smartmontools. It's just that the purpose of smartmontools is exactly to find out if it's working or not, and we can't know for sure without...

I made a quick comparison of the releases 6.4 and 6.5:
https://www.smartmontools.org/changeset?old_path=%2Ftags%2FRELEASE_6_4%2Fsmartmontools&old=&new_path=%2Ftags%2FRELEASE_6_5%2Fsmartmontools&new=&sfp_email=&sfph_mail=

That's a lot of changes. On the other hand, backporting of the NVMe related changesets seems to be spread over many commits, so I'm not sure if that is the better option...