This is the seventh and eighth post (combined into one) in the series of my weekly GSOC Sugar Labs, where I summarize my week of working with Sugar Labs under GSOC.
In the following bi-weekly period I worked on the aslo-v3 along with Samuel. We worked on improving the aslo-v3, adding functionalities and fixing bugs. Since GSOC code review is approaching fast, it was very exciting and adrenaline driven experience. One important feature was to support both release with and without prebuilt bundles. It took some thinking to support both and we had to branch out build pipeline to support both cases. I created a test orginzation named sugarlabs-test to develop aslo-v3 and debug issues. Github Webhooks was addded to workflow since it lets you to replay webhooks as many times you want and it helped debug issues with a particular release. To recieve locally I used ngrok and then settled on ultrahook since ngrok provides namespace static url for free while to get a static url we have to switch to non-free model, but ultrahook only lets you receive POST events which ngrok supports all verbs and lets tunnel all traffic. Identification between a asset and non-asset release was simple. An asset release has an asset object in the json payload. Here is an example
For asset release we download the bundle by checking asset for first valid .xo file (valid in the sense, it should have activity.info) then we store the bundle in appropriate directory, parse json and insert into it json.
A decision was to made support mutliple releases, aslo-v3 will store new and old releases, in case user want to download a particular version but by default only release will be shown and old releases can be accessed via a More Download/Advanced Options. To keep track of things, Samuel and I jotted down things in a shared Google Keep List. To collect release notes we will be using [release][body] and render them on Frontend, since it’s just makrdown.
Samuel was kind enough to refactor all the code and send a PR. Now most of the recent changes can be seen in refactor branch. New refactored code is much more organized and easy to follow. It uses error handling by raising instead of relying on return values which reduced amount of code needed. Samuel aslo simplified the Docker.
and build process and I added/refactored rest of the code. We switched back to fedora-22 since most of the activities are tested in Fedora (SOAS is also built upon Fedora) and it would save us from weird errors that may arise due to dependency on fedora on activity.
Samuel was also kind enough to give me a walk through and explain code via Google Hangouts .
Samuel aslo suggested me to talk to Chris Leonard and discuss the localization process with him and how NewAslo can be used for localization.
Also it was decided to invent a heuristic to detect Sugar version for which I reused the SamToday’ code. It was also decided to use Mongoengine to provide some structure to DB specific code and ORM really does reduces the code. We also pondered upon the schema and discussed the one big documents vs many small/moderate collections, each for activity.
Samuel came up with following schema (still iterating over )
Qutoing my mentor Samuel
I have had a conversation with Walter and we are thinking to point out to old url releases.
So this collection is right place! Probably we'll end up writing a script to fill in theses
releases documents. Big work!
Why? Because we believe the only way to kill aslov1 is to shut it down!
A solid schema is needed if we we aim to serve users and replace old aslo.
Only challenge we are yet to decide is the use of Mongoengine’s DynamicDocument and EmbeddedDynamicDocument classes for storing dynamic documents with dynamic keys, mainly for storing different translations of summary,name and changelogs.
Goals for Next Week
I have GSOC code review this week, so I hope I pass the review (wish me luck ) so I can continue working on aslo-v3 and make it successful.