hi;
> On 2 December 2013 10:56, Aliaksei Katovich <[1][email protected]>
> 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 :-)
Consensus! Great! \o/
> 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?
Software issues can be manifested later, after update is applied but
user is not anymore with PC at hands.
>
> [...]
>
> 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.
Ok, i misinterpreted this, sorry.
> [...]
> > 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
It was just first impression :)
> 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.
That's why simple and easy way to rollback is important.
> > 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.
Snapshot based rollback will reconstruct one's device in no time.
> > 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.
The feature proposed is area/connection agnostic: it _makes_ sense
to rely on rollback regardless whose product and where it is. IMHO.
But I see your point.
> > - 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.
PC's world end is behind the corner! ;) Sorry for silly joke though
could not resist.
> > 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?
Sounds like alternative despite being very implementation specific.
> 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?
how about these:
* complex solution (reconstruction) vs simple (thin-provisioning);
* if I understand you correctly reconstruction implies package
re-installation which might become a problem due to:
- time consumed;
- space consumed;
- dependencies;
* how to rollback in case reconstructed configuration failed: files on
system got already replaced with new ones;
* how to recover from update if connectivity framework gets broken right
after.
IMO snapshot based rollback is cheaper to make and maintain than
rebuilding.
--
Aliaksei
> --
> cheers, igor
>
> References
>
> 1. mailto:[email protected]
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
