hi;
> one more doubt
> On 2 December 2013 12:04, Stoppa, Igor <[1][email protected]>
> wrote:
>
> âHi,â
> On 2 December 2013 11:45, Åukasz Stelmach <[2][email protected]>
> wrote:
> Â
>
> Please consider upgrading tens (hundreds) of thousands units. If you
> break them OTA you have to fix them OTA. You won't make N (where N ~
> 1E5, you may be lucky enough to make 10% of you customers download
> flashing software for PC that still gives 90k) customers visit
> repair
> shops. You don't have that many repair shops to fix such failure (in
> reasonable time).
>
> Â
> âI agree that, presented from this perspective there is a point to it.
> Questions: how likely is it?
> Of course even if it's unlikely one doesn't want to be the responsible
> for the failure.
> AFAIK nobody has yet managed to cause such massive failure on the
> field.
There are cases but i'd rather not point at them (google search will
instead).
> But let's assume that, since it's better to be safe than sorry, some
> mechanism has to be deployed,
> I'm still not sure that btrfs is the right answer. Not for btrfs per
> se, but rather because the rollback
> would happen at a very low level which has no knowledge of what is
> really going on. â
> There should be also some mechanism to re-align with the user data
> stored in the cloud,
> which âmight have diverged significantly, in case the rollback happens
> significantly later on, after the upgrade.
versioning control for configs?
> What happens to apps that have been upgraded and are not compatibleâ
> with the older
> OS revision?
How can they be upgraded being incompatible with OS in the first
place? Package manager should not allow this.
> The new app might even have changed the config format.â
And even this happens then:
a) app should take care about configuration compatibility itself
or
b) we could use VSC for config files (GIT?)
--
Aliaksei
> --
> cheers, igor
>
> References
>
> 1. mailto:[email protected]
> 2. mailto:[email protected]
> _______________________________________________
> Dev mailing list
> [email protected]
> https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
