Yes, please finish what we started. Please just complete the work for
the stand alone app and spec out the implementation for the proper
design after we have click working well from end to end. I don't think
entangling click with the rest of the system at this late stage will
succeed in time for release, and I don't think we can should consider
a system where you cannot update apps.
Cheers, Rick
On Tue, Sep 10, 2013 at 1:14 PM, Roberto Alsina
<roberto.alsina@xxxxxxxxxxxxx> wrote:
Hello!
First some background:
Recently (Aug 29th) we got the design for the tool that would "upgrade all
apps that need upgrading" from mpt.
That design calls for it to be integrated into settings, and integrated with
system updates. Diego Sarmentero was already advancing work on it, as a
standalone app, so that we could have something to iterate on.
A couple of days ago, he started work on integrating it into settings, and
... it's not going well.
Basically, the updates module in settings is tightly coupled to the system
update daemon and the API was designed for that case. The UI design of it
changed a lot as well with this design update. So, to prepare for the
future, we'll need to work on the system update daemon, and also the ui,
taking into account both cases while cleaning up the code. This can be some
extensive work
This leaves us with a few less than ideal options:
1. rewrite that now, and delay the global click updater
2. rewrite later and ship the global click updater as an app now
Since the spirit for september is "finish what we started", both Didier and
I feel the best path forward is to ship the click
package updater as a standalone app, specially considering the security team
considers this a critical feature.
Feedback encouraged, of course.
