Developing and Deploying devices

[Tim Wootton]

On 12/04/16 15:58, Dirk Hohndel wrote:
>
> Seriously, we need to very very very clearly separate two user groups:
>
> A) people who are comfortable installing debian on some random device
> and making all this work
> B) actual divers and users of Subsurface-mobile on their iPhone with no
> discernible knowledge of computers
>
> On every dive trip I'm on I somehow end up meeting about zero or one
> people in group A and everyone else is in group B. For group B we should
> pick ONE device, ONE solution, ONE way of doing this. Keep it as simple
> as humanly possible.
>
Just wanted to throw this in as a suggestion:

To make upgrades and upgrade-backout as seamless as possible for group B
, how about having the main software as a complete read-only chroot
image provided by the project? You'd have just enough on the bare metal
to select the latest chroot image (or last known working on failure) and
switch to it. That way it could have a one-click (or possibly no-click)
upgrade. You could keep the last 2 or 3 images for backout purposes.
This avoids the situation where devices get into a state that requires
user intervention because one or more .deb fail to apply properly.

apt-get could still be used by the project team to make the images,

I think of this more like an Android or iPhone upgrade that applies a
complete image rather than a desktop upgrade where you take individual
packages, The difference though is keeping backout images and
automatically failing back in case the new image fails load for some
reason.

This also has the advantage that someone troubleshooting will be able to
know, for a particular version, exactly what software the user has on
the device without worrying about which packages they may or may not
have picked up along the way.

The disadvantage is that a full image download is needed for each
upgrade, which provides an intensive to make it as minimal as possible.
Group A users can always side-load their favourite tools after updating.

cheers,

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160414/0ce0082d/attachment.html>