[Dev] [RFC] Tizen system rollback

Stoppa, Igor igor.stoppa at intel.com
Mon Dec 2 09:16:26 GMT 2013


Hi,


On 2 December 2013 10:56, Aliaksei Katovich <a.katovich at samsung.com> wrote:

>
> >    Rather, it ought to be "what is currently flashed in the factory".
>
>         I do not see any issues with supporting this concept in proposed
>         approach.
>

Me neither :-)
But it was not part of the proposal, iirc. So I brought it up.

[...]

 >    Sorry, but I cannot agree with this.
> >    You are somehow implying that the end user would not be able to flash
> >    the sw
> >    on a bricked device.
>
>         This sounds like a real statement rather than implication to me:
> User
>         will not be able to restore malfunctioning after update device
> being
>         away from PC or being not connected to network.
>

How likely is that? Like users are advised to do upgrades with full battery
charge
and possibly charger plugged in, wouldn't it be advisable to tell them to
do the update
when they have a PC with broadband connection handy?

[...]

        Again, OTA upgrades are already part of our lives - so it is not
> just
>         nice but rather mandatory thing nowadays.
>

I wasn't trying to say otherwise.

[...]

>    Final few considerations:
>    1) given the dynamics of how testing works and the fact that testing
>    teams
>    have only so many devices available, it's much more likely that cold
>    flashing gets
>    significant more testing than OTA. I won't get into details, but it's
>    obvious that they
>    have to test many releases and typically the testing starts with
>    flashing a new image.
>    Only a limited amount of devices are reserved to real OTA updates,
>    because it
>    requires more complex IT infrastructure.

        I do not see your point here. Are you trying to say that no new
> features
>         should be added because testing is hard to arrange?
>

C'mon ... do you really think I'd write that? :-D

No, what I mean is that, no matter how hard the QA team tries to test
OTA, the way the product program works is playing against them.
It's a fact: just think how many times OTA is attempted vs how many
times flashing is performed.
The latter wins hands down. Not to mention that typically one cannot use
exactly the same production environment for testing OTA, so there are bound
to be parts of the OTA process that will never be really tested until it is
deployed for real on production servers.
This doesn't apply to flashing.


> >    2) alternatively, one could use cloud storage to keep track of user
> >    data
> >    and configuration (like apps installed and related keys) and just
> >    rebuild the user's
> >    customized setup on top of a new build.
> >    Even with a rollback, there will be the problem that the use might
> want
> >    to re-install whatever
> >    was non-offending and got installed in between the restored snapshot
> >    and the failure that needed reset.
> >    And even re-installing, the user data might be in a non-consistent
> >    state.
>
>         This is far less tested than anything.
>

That's

a problem because it's far more likely that a user has to deal with a
broken/stolen/lost device hat needs to be reconstructed somehow.


> >    3) how to decide to take a snapshot?
> >    - let the user choose
> >    - whenever some native app is installed
> >    - before a distro upgrade, like windows does?
> >    - a mixture of the options above
> >    If I were to decide, probably I would either do it all the time or
> >    misjudge and skip it when
> >    it would really turn out to be useful. Probably I would do both :-)
> >    The rollback, to me, makes some sense only in certain corner cases,
> >    like:
>
>         s/corner/vital/
>

Of course you know your product better than me, so if it's going to some
rural area in africa or india where connection is
unavailable/slow/expensive,
it might make sense to rely on rollback.


> >    - no access to broadband connection
> >    - no access to a PC
> >    - hard requirement of 99.999% availability
>
>         those three above _are_ real! Look:
>
>         User received update being connected to internet. Update worked
> just
>         fine first two hours and then something started to malfunction.
> User
>         has no data connectivity nor PC accessibility at that point of time
>         but desperately needs stable working device. Maybe it _can_ be
> called
>         a corner case but to me _possibility_ to restore device to known
> working
>         configuration regardless of connectivity status or PC availability
> is
>         extremely important.
>

As I wrote, it depends on the product requirements.
If PC w/ broadband connectivity is available, then

the requirement on rollback is not so hard.

>    So it might fit cases where you have rural users, but if we can assume
> >    that the
> >    device is targeting city dwellers, the reconstruction seems more
> >    attractive.
> >    Which is btw, what Apple does.
> >    I'm not saying that it's right just because they do it, but certainly
> >    we will all agree
> >    that they have a large use base which is not necessarily tech savvy
> and
> >    yet they
> >    manage to keep the bricking to an acceptable level.
>

What do you think of what I wrote above?
Why not just rely on rebuilding the device configuration?
Is it just because of the requirement of PC/broadband or is there any other
reason?


-- 
cheers, igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131202/7f0d802c/attachment.html>


More information about the Dev mailing list