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.

Openembedded-core mailing list

Reply via email to