[Sugar-devel] [DESIGN] optional automatic updates

[Martin Abente]

On Thu, Aug 7, 2014 at 8:26 PM, Jerry Vonau <me at jvonau.ca> wrote:

> Hi,
>
> > On August 5, 2014 at 7:34 PM Martin Abente
> > <martin.abente.lahaye at gmail.com> wrote:
> >
> >
> > Hello everyone,
> >
> > A few development cycles ago, dsd added a useful new feature: automatic
> > activities updates.
>
> Um, sugar 0.100 was not that long ago, kind of liked the way the old
> sugar-update-control worked, all that was really missing was the
> auto-updating. For the record there never was a sugar-control-panel command
> line for the updater, that was the only piece missing. When I was involved
> with AU we went further, extending the updater to just select activities
> that were already installed, leaving the ones not installed unchecked by
> default. This presented a list of optional activities that MAYBE installed,
> ones that are updates would be pre-selected, one just needed start the
> install[1].
>
> > This has been of great help in deployments such as in
> > Australia. However, because the current implementation will always update
> > or install activities (when working in automatic mode), some deployments
> > might be unable to use this feature. A real case scenario is when some of
> > the activities are too big for massive activities updates.
> >
>
> Think one option that is needed is to skip installing new activities that
> are not already installed.


Installing new activities could be needed too. Both cases are valid though,
and is ultimately a deployment's decision. This feature can help with both
for new install AND updates.

The whole point is to give deployment the flexibility, so we (developers)
don't make the decision for them (deployments) for what should or should
not update.


> The use case is "the in the field teacher" does
> not want a certain activity present for what ever reason on the XOs in
> their classroom and has removed the activity.
>
> > Therefore, I propose to extend microformat updater with an extra field to
> > mark activities as optional, so these optional activities won't be
> > installed or upgraded automatically. This flexibility will allow
> > deployments to use automatic updates and user will benefit from automatic
> > updates.
> >
>
> Think this is not really needed, more careful planning by the deployment is
> really what is needed here.




> > I have created a feature page [1] with more details and a initial
> > implementation [2] of the feature itself (because is easier for me to
> > talk
> > with working code).
> >
>
> Would ALSO benefit with the same treatment? Think that is where this could
> be really be useful, stopping a potentially large download from starting.
>
>
You mean supporting this in ASLO?


> > Let me know what you guys think!
> >
> > Regards,
> > tch.
> >
>
> At one point in the past suagr-update-control did have the ability to look
> for a schoolserver, adding the activities found there to the list of
> activities available from both sources. That went away with the change in
> sugar's post 0.100 updater.
>
> Jerry
>

Thanks for the feedback!


>
> 1. http://bugs.sugarlabs.org/ticket/2822
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140807/4845ab1f/attachment-0001.html>