On 08/18/2015 10:54 AM, Martin Jansa wrote:
Now we see a lot of upgrades in oe-core which are done by people just because "package upgrade report" says it's possible and the upgrade is tested mostly by autobuilder (which doesn't exersize any "extra" layers and runtime-test coverage is very low) - so in the end many of these "good to have" upgrades are breaking some other components which aren't upgraded so often or breaking/changing runtime behavior and only couple months later someone who is actually using them will report that.
The alternative isn't great either. Older, out-of-date software tends to require more effort to backport security fixes and prevent bitrot (maybe as much effort as would be spent simply updating it to latest versions). Or if no one does the backporting then you have an insecure software stack.
Then, when gigantic, must-have updates happen, they take forever to prepare, review, (rebase, update, review)* and merge, they're met with more resistance, and cause even more breakage and pain in the other layers than if the same thing would have been achieved via small, incremental updates.
Test automation is being worked on, so when that is in place, then rolling, small updates approach will be clearly superior.
Regards, Alex -- _______________________________________________ Openembedded-core mailing list Openembeddedfirstname.lastname@example.org http://lists.openembedded.org/mailman/listinfo/openembedded-core