[Systems] [Sugar-devel] New ASLO Bundles on the Mirror

[Sam P.]

Hi Bernie,

On Wed, 7 Jan 2015 12:12 pm Bernie Innocenti <bernie at codewiz.org> wrote:

On 01/06/2015 07:59 PM, Sam P. wrote:

> But that is only 1/2 the bundles.  For every commit that the bots are
> notified about, the new ASLO builds a bundle as a development/latest
> copy.  These are available in the new ASLO UI as devel version bundles.
> I plan to purge these on a cron job, so there is only 1 on the sugarlabs
> servers for each activity.  But this does mean that we have lots of
> bundles that are not on the old ASLO.

We also need a way to keep around multiple bundle versions for the same
activities. There are various reasons for this:

 - Bundles for older versions of Sugar (initially we may need to support
only the latest Sugar which gets the new bundles, but eventually we'll
end up with the same situation we have today in the old ASLO)

 I doing that already :)
It works in updater, ui and back end.  I revert to the latest version with
support for that sugar version.  Testing appreciated.

 - Binaries built for different architectures (i686, x86_64, arm...)

 Do you have an example for this?  I tried physics, but it does not have a
native part.  I will try and use git-annex or a similar solution, as
discussed on irc.

 - Bundles manually pinned by deployments. This is crucial for
deployments that do their own QA and can't tolerate breakage during the
school year. The ASLO updater never supported this very well, and thus
many large deployments kept using the "microformat" updater along with a
wiki page or a static html page hosted on their infrastructure.

 IMHO, deployment can easily deploy their own new ASLO copy and manually
edit or rollback or not update the data files.  It is relatively easy to
deploy your own new ASLO frontend and updater dataset (part of frontend).
I should probably reach out to developments doing this.

Sorry for dropping so many new requirements on you, but... Replacing a
production system is a lot harder than designing something anew :-)

 That's fine :)

Thanks,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/private/systems/attachments/20150107/cfabb7f5/attachment.html>