On 3/18/19 10:39 AM, Richard Purdie wrote: > 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).
Yes, absolutely. I'm saying by policy we do this. Since I'd expect any stable upstream to have an existing changelog available. (Either in git, or in a changelog file.) For those upstreams that claim a stable release, but don't actually have a changelog -- I'd be suspect of their practices.. but simply pointing to an upstream 'announcement' with content changes is equally as good for those that handle it that way. > To give more context, do you/I really think we have a better idea of a > fix that the kernel maintainers themselves? You and I, likely not.. (and that applies to any upstream). However, You and I have a better understanding of what we believe 'stable' means, then someone else would. This is where we need the policy to align. I trust an upstream maintainer to say this is a 'good change'. But what I don't trust them to do is make a tradeoff of 'this is a good change' vs 'this is a necessary change'. The later to me is what defines a stable update vs development. Looking at an abbreviated commit log/changelog can give people the confidence that this update had 4 changes in it -- vs 4000 changes. 4 to my non-[community]-informed eye says it's a minor change, while 4000 makes me question a lot of things. Move this to the kernel. The 'stable' upgrades in the kernel are often on the order of 100-500 commits in my experience. Over time you can watch the trends of the quantities, as well as the trust of those maintainers and reconcile whatever the stable upgrade counts are for any given project... My point is there is no one right answer, all we can do is our best -- and with a bit more information I think the answers become more clear to us and the people around us. If that additional information is not available, then I'd contend the necessary trust in that community is likely lacking as well and our existing process may be the best for 'stable'. --Mark > Cheers, > > Richard > > _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
