Make Sailfish more modular

asked 2015-05-16 00:40:02 +0300

rdmo
3529 ●97 ●123 ●129

updated 2015-05-16 10:54:45 +0300

tl;du Successful upgrades are reported less often than failures, but is there a better way to deliver upgrades?

Reports of bricking make me extremely wary of updating. Please isolate and stabilise future releases and then upgrade the core modules separately from closed source blobs, add-ons, etc. The current way updates get released seems to create problems. Whether all such problems, real or imagined, are better for business/users, is left as an exorcism for the reader.

And please don't force upgrade paths to include all previous - including problematic - updates. This will potentially cause trouble for every user, whether they hesitate to update or opt to be included in updates ahead of most users. Upgrading a program or module at a time improves easy tracing of causes. Kindly make sure upgrades are workable from any previous version to each current release.

Given the capabilties of btrfs and git, is this incremental method of updating and bug-or-feature tracking viable? While not knowing internal procedures and practices pretty much disqualifies the following as anything more than naive conjecture, this incrementality could surely improve code auditing and enhance workflows to produce more rigourously tested and responsibly committed code, and make clear when a problem is within or beyond Jolla's reasonably expected diligence.

answered 2015-05-16 12:27:40 +0300

Okw

4369 ●53 ●62 ●69

Supporting all possible upgrade combinations introduces more breaking points. By having only one upgrade path for everyone is actually less of a risk. It's less work and easier to debug upgrades from say C to D, than having to support upgrading from A, B and C to D. Supporting such usually requires all sorts of workarounds, which makes many things bit of a mess.

edit flag offensive delete publish link

Comments

Why aren't upgraded binaries/libraries installed as if new? I realise this is not as simple an issue as the question might seem to imply - I would like to understand the reasons or reasoning in a little more depth than knowing there are forward-compatible and incompatible API changes.

Does the Sailfish development process use any kind of predictability or compatibility modelling?

rdmo ( 2015-05-16 18:34:31 +0300 )edit

Not sure what you mean by "...development process use any kind of predictability or compatibility modelling?", but I'm guessing you've never actually dealt with a developement process.

Why try to model something as simple as dependency chains? Think of the recent Qt upgrade for example. Since everyone was forced to install the new Qt, the Sailfish dev team doesn't have to care about supporting previous versions of Qt. Thus they have less software to put into testing phase. Quite simple, isn't it?

I'd rather have the dev team focus on polishing RCs than modelling utopia.

Okw ( 2015-05-16 18:52:01 +0300 )edit

You may guess wrong in this way but it is not terribly polite, nor is it helpful. To assume introducing more breaking points may also assume or imply poor coding, testing or QA. These are unsubstantiated.

Compatibility models might include reports with automated source diffs and changes to what expression, lines or functions will fail to execute and whether the failures will be silent, symptomic or fatal. Directed and other graphs might help to visualise pressure points in the code.

rdmo ( 2015-05-16 21:23:40 +0300 )edit

Make Sailfish more modular

1 Answer

Comments

Question tools

Stats

Related questions

Make Sailfish more modular

1 Answer

Comments

Question tools

Public thread

Stats

Related questions