On Mon, 2019-03-18 at 10:26 -0500, Mark Hatle wrote: > Let me start out with, I'm not against this proposal. > > But, I want to mention the cases in my experience where people get > upset with version numbers changing. > > 1) "Regulated devices". For some reason there are a class of devices > where some sort of government regulation says you have to re-certify > the device if internal components change version numbers. So for > these users they would rather the version number never change, and > all contents be backported. (Even if the backport effectively > changes the software base other then the version number.) > > Fortunately a lot of these industries are changing, and focusing our > policy on allowing someone to workaround a specific regulation seems > like a bad idea.
Exactly. This is a case where "someone" needs to go and educate them that their regulations/policies no longer align with best industry practise. Allowing version changes in the core of the project stable policy is actually an important part of spreading acknowledgement of this. > 2) Business reasons. Customers who are so risk adverse that they > believe every > commit needs to be validated before they can possible accept the > upgrade. > Focusing on backports gives them the confidence that they are able to > review all > of the changes that a minor (stable version) upgrade does may not. > > Perhaps becomes part of the criteria we use for stable version > upgrades? Stable > versions have bug fixes that are in a small enough quantity that they > can be > reviewed? > > Along those lines, perhaps our policy should be to include with a > stable upgrade > a changelog or other list of the upstream changes in our own commit > logs to help > reassure these users? If we have resources to do that, sure but I see it as a nice to have. Where there is a known good source of data I am strongly in favour that we trust the upstream (e.g. kernel-stable, openssl, webkit). To give more context, do you/I really think we have a better idea of a fix that the kernel maintainers themselves? Cheers, Richard _______________________________________________ Openembedded-architecture mailing list Openembedded-architecture@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
