[ASLO] ASLO build and deployment process (Jatin Dhankhar)

[Jatin Dhankhar]

Hi,
Where should I start? Should I start working on the new ASLO ?

Thanks,
Jatin Dhankhar

On Sun, Apr 2, 2017 at 4:28 PM, Jatin Dhankhar <dhankhar.jatin at gmail.com>
wrote:

> Hi Tony,
>
> Based on our suggestions I updated the proposal, thanks a lot for your
> inputs. https://docs.google.com/document/d/1wECi_
> gtxyar3MWbC8ly6bjdW8SSLYe5YNcXPiTUUlkg/edit?usp=sharing
>
>  the new version assume the master source repository is github and that
>> bundles are installed and updated via setup.py from github
>>             (the build and deployment methodologies). This means the new
>> system does not need to implement the Developer Hub.
>
> That seems a nice idea but won't there be need for moderation/approval of
> activities.
>
> Add recommendation engine - I think this is a distraction. How can a
>> program know the interests and needs of a user to provide a useful
>> recommendation? I also think the Review system is a distraction. The
>> problem is that no reviews come from actual users of the activities but are
>> similar to the sponsored reviews at Amazon. A better approach would be to
>> strengthen the tags/collections/category system.
>
> This can be useful if we want to show user, programs similar to what user
> already installed or suggestions based on what users installed along with
> following app but that is quite a work, we need to add analytics and stuff.
> Tags/collections/category is a simple way to achieve this nicely.
>
> Improve look/theme of ASLO - Naturally, this should be done in the
>> context of the project.
>
> Yes, I am looking at http://beautifulopen.com, for awesome examples.  I
> am liking these so far http://rouge.jneen.net/ and http://www.gnu.org/
> software/guile/.
>
> I want to get started with discussion of potential design and tools for
> deploying activities.
>
> Thanks,
> Jatin Dhankhar
>
> On Sun, Apr 2, 2017 at 9:58 AM, Tony Anderson <tony_anderson at usa.net>
> wrote:
>
>> Hi, Jatin
>>
>> The most important thing to keep in mind is that ASLO manages a library
>> of independent programs (Sugar activities). These are updated
>> asynchronously from the Sugar releases. Sugar is in desperate need of build
>> management - as best I can tell at the moment we have none. However, this
>> problem does not directly apply to the activities.
>>
>> The 'build' process for the activities is accomplished by 'python
>> setup.py dist_xo' executed in the bundle root. The generated xo file is
>> then 'deployed' to the appropriate directory in download.sugarlabs.org
>> as the latest version.
>>
>>
>> Since development time in GSOC is limited, it is critical to define a
>> doable project. In my experience proposals set unachievable expectations
>> and result in partially complete and disappointing results.
>>
>> Improve look/theme of ASLO - Naturally, this should be done in the
>> context of the project.
>>
>> Maintain ASLO - I am proposing that this project build a replacement for
>> ASLO which can be used immediately offline by school servers. During the
>> GSOC period, the community should be expected to judge whether the
>> development forms a base for future replacement of ASLO.
>>
>> Add recommendation engine - I think this is a distraction. How can a
>> program know the interests and needs of a user to provide a useful
>> recommendation? I also think the Review system is a distraction. The
>> problem is that no reviews come from actual users of the activities but are
>> similar to the sponsored reviews at Amazon. A better approach would be to
>> strengthen the tags/collections/category system.
>>
>> Improve Transactional emails - I think this is also a distraction. The
>> user communication is clicks on links. The response is public.
>> So I would propose something like:
>>
>>         - develop a new ASLO as activities3.sugarlabs.org based on
>> Django (to this end I can supply my current minimal working version).
>>
>>         - the new version assume the master source repository is github
>> and that bundles are installed and updated via setup.py from github
>>             (the build and deployment methodologies). This means the new
>> system does not need to implement the Developer Hub.
>>
>>         - the core activities (Journal, Record, Log, Terminal, Write,
>> Jukebox, Image Viewer, Browse, and Read) be excluded from ASLO and handled
>> through the                 Sugar release cycle). These activities are
>> installed in a Sugar release and the ability to erase them is disabled.
>>
>>         - for simplicity, the initial version could be limited to two
>> templates: an index page showing icons and names of activities and a page
>> per activity with the download button.
>>
>>         - There should be a simple and transparent 'CRUD' capability for
>> the metadata - perhaps in the first commit based on Django's admin feature.
>> I think the first commit db could consist of a single table: one row per
>> activity.
>>
>>         - Do whatever can be done to improve the attractiveness of the
>> site.
>>
>>         - Do not base development on emulation of any other project:
>> Mozilla add-ons or Play Store or .... Certainly the project can and should
>> be take inspiration                 from any source. However, it will be
>> enough to attempt to provide the essential current functionality of ASLO.
>>
>> What I visualize is the project be installed on github at the point of a
>> first working commit. The project could then be installed as
>> activities3.sugarlabs.org for community testing and advice. Development
>> would be using git locally using localhost or a local server. Commits would
>> be pushed to GitHub at appropriate points in the development and the
>> resulting version would then be used to update the online version. The
>> project would work with the current download.sugarlabs.org as the source
>> of bundles. (therefore, keeping the addition of activities to GitHub as a
>> separate project).
>>
>> Keep in mind, I am speaking for myself. While, if your project were
>> selected, I would probably be a mentor - this gives me no special voice in
>> the selection. Normally we have several proposals for each available slot
>> and many worthy proposals are not selected.
>>
>> Tony
>>
>>
>> On 04/01/2017 09:29 PM, Jatin Dhankhar wrote:
>>
>> Hi Tony,
>>
>> I think the same, as per commit history project didn't get much attention
>> recently.
>>
>> The website itself is implemented in PhP and is patterned after the
>>> Mozilla addons site.
>>
>>
>> Yes, the README mentions it's based upon Remora(http://wiki.mozilla.org
>> /Update:Remora ) which old and deprecated now in favor of AMO (
>> <https://wiki.mozilla.org/AMO:Developers>https://wiki.mozilla.org/AMO:
>> Developers) .
>>
>> At the moment I am trying to find out which of the activities actually
>>> work in the current release of Sugar. The library currently has about 600
>>> activities. A Sugar activity is intended to be self-contained (any
>>> dependencies not satisfied by Sugar are to be incorporated in the bundle).
>>
>>
>> I think it's a moonshot but I am thinking to include a testing suite to
>> determine whether a current version builds against a certain sugar version
>> by using a CI or something like  OpenSuse's QA (http://open.qa/) for
>> more comprehensive suite.
>>
>> How this will be done is a mystery to me. Logically, each of the versions
>>> of an activity should be commited in git so that a developer (or
>>> maintainer) can the changes made over time.
>>
>> Yes, that seems right thing to do, last year Arch Linux shifted all their
>> AUR packages to a git backend, maybe they can help, I can try finding
>> persons who carried out the transition.
>>
>> If you look at the ASLO site, it seems clear that the page needs to
>>> specify more than which versions of Sugar are supported. It will need to
>>> specify which models of the XO are supported. It will also need to mention
>>> any restrictions on architecture or peripherals needed for the users system
>>> (microphone, camera, network connection - wired or wireless, and so on).
>>
>>
>> Yes more like a Manifest, similar to what Play Stores does for Android.
>>
>>  My plan is to use Django (which enables code to be in Python and not
>>> PhP). The school server already provides sqllite, mariadb, and postgresql
>>> so db support is readily available. Django is designed to support fusion -
>>> creating web pages dynamically based on information from a db and so should
>>> match the requirement.
>>
>> Yes, re-write seems a reasonable choice. One thing that I am curious is
>> that current repo suggests that it's is a mix of Python and PHP and going
>> full python would be a great move, in my opinion.
>>
>>
>>> Just for further background. Many deployments I work with have no access
>>> to the internet. To provide an alternative, I support a school server which
>>> XO users can access by wifi in the classroom
>>
>> I think point makes a strong case for easily replicable instances of ASLO
>> with little to no configuration on the user side, which means we need to
>> make a simple and consistent build process so that users can run their own
>> versions of  ASLO easily. Docker is a option worth looking into.
>>
>> I hope you will consider this challenging and not discouraging.
>>
>> Yes, I find it equally challenging and interesting.
>>
>> I made a proposal ASLO that shares some of the concerns that you
>> discussed . Kindly take a look and let me know what do you think of it.
>> Here is the proposal link
>> <https://docs.google.com/document/d/1wECi_gtxyar3MWbC8ly6bjdW8SSLYe5YNcXPiTUUlkg/edit?usp=sharing>
>> https://docs.google.com/document/d/1wECi_gtxyar3MWbC8ly
>> 6bjdW8SSLYe5YNcXPiTUUlkg/edit?usp=sharing
>>
>>
>> Thanks,
>> Jatin Dhankhar
>>
>> On Sat, Apr 1, 2017 at 3:20 PM, Tony Anderson <tony_anderson at usa.net>
>> wrote:
>>
>>> Hi, Jatin
>>>
>>> The ASLO site is in desparate need of work. At the moment I am trying to
>>> find out which of the activities actually work in the current release of
>>> Sugar. The library currently has about 600 activities. A Sugar activity is
>>> intended to be self-contained (any dependencies not satisfied by Sugar are
>>> to be incorporated in the bundle). Naturally, an activity should work on
>>> any Sugar. However, this situation is becoming very complicated. First, two
>>> of the XO models (1 and 1.5) have Intel 32 bit architecture processors. The
>>> others (1.75 and 4) have Arm processors. Some of the activities incorporate
>>> binary modules which limit their use. The Sugar community wishes to support
>>> Sugar on a range of platforms. For mobile devices, Lionel Laske is
>>> developing Sugarizer. While traditional activities were implemented in
>>> Python (with some binary exceptions using Java or C), Sugarizer activities
>>> are written in Javascript (HTML5 and CSS). Naturally a trend in modern
>>> computers is to 64 bit architecture (AMD 64).
>>>
>>> The website itself is implemented in PhP and is patterned after the
>>> Mozilla addons site. It has a repository of activity bundles (.xo files)
>>> which is visible at <http://download.sugarlabs.org>
>>> http://download.sugarlabs.org. Each activity has an 'add-on' id
>>> (4000-4999 at the moment). Versions of activities are numbered beginning
>>> with 1 and incrementing by 1 with subsequent versions. So the directories
>>> in ASLO contain bundles for multiple bundles with the highest numbered
>>> version considered the latest. In addition to the bundle, the site contains
>>> metadata which is displayed in the pages devoted to an activity. I suspect
>>> this metadata is stored in a database but I haven't investigated to find
>>> out the details.
>>>
>>> In the meantime, Sugar Labs has decided to create a repository for
>>> activities in github. The reasoning appears to be that this will make it
>>> easier for the community to undertake ongoing development and maintenance
>>> of these activities. Currently, the ASLO site has a 'developer hub' which
>>> allows registered users to add or update their own activities. This
>>> function will need defined and moved to github.
>>>
>>> How this will be done is a mystery to me. Logically, each of the
>>> versions of an activity should be commited in git so that a developer (or
>>> maintainer) can the changes made over time. Also, some method is needed to
>>> manage over 600 additional repositories in the Sugar Labs github.
>>>
>>> If you look at the ASLO site, it seems clear that the page needs to
>>> specify more than which versions of Sugar are supported. It will need to
>>> specify which models of the XO are supported. It will also need to mention
>>> any restrictions on architecture or peripherals needed for the users system
>>> (microphone, camera, network connection - wired or wireless, and so on).
>>>
>>> Over time, Sugar has dropped many packages which were ordinarily
>>> included. This has rendered many of the activities currently unusable. For
>>> example, Sugar switched from a browser based on hulahop to one based on
>>> WebKit. Some effort will be needed to update activities using hulahop to
>>> use WebKit. Sugar Labs hopes that activities will be ported to GTK3 (called
>>> sugar3) from the original GTK (sugar). If this can be accomplished, the
>>> size and complexity of Sugar can be significantly reduced.
>>>
>>> I hope you will consider this challenging and not discouraging.
>>>
>>> Just for further background. Many deployments I work with have no access
>>> to the internet. To provide an alternative, I support a school server which
>>> XO users can access by wifi in the classroom. My hope is to provide a
>>> version of ASLO on the school server which will give these users the
>>> ability to install any of the activities they choose and for which their XO
>>> has storage capacity. That capability exists now (and has for some years).
>>> However, the selection is basically a list of activities by name and does
>>> not provide the metadata descriptions found on the ASLO pages. My plan is
>>> to use Django (which enables code to be in Python and not PhP). The school
>>> server already provides sqllite, mariadb, and postgresql so db support is
>>> readily available. Django is designed to support fusion - creating web
>>> pages dynamically based on information from a db and so should match the
>>> requirement.
>>>
>>> Tony
>>>
>>> On 04/01/2017 04:00 PM, Jatin Dhankhar wrote:
>>>
>>> Hi Tony,
>>>
>>> There are two major elements to Sugar. The desktop interface - Sugar and
>>>> the activities. ASLO is a library of these activities. Build only applies
>>>> to Sugar.
>>>>
>>>> For a non-XO version of Sugar, there are two easy choices: SOAS and
>>>> Sugar on Ubuntu. For Ubuntu, install 14.04 or more recent version (I am
>>>> using 16.04) and execute sudo apt-get install sucrose. For SOAS, download
>>>> the image and dd it to a usb stick. It works as a livecd.
>>>
>>>
>>> Thank you for all the information :)
>>>
>>> Make Your Own Sugar Activities!
>>>> By James Simmons
>>>> <http://www.lulu.com/shop/search.ep?contributorId=739770>
>>>>
>>>> Make sure to get the second edition.
>>>>
>>> Specially the book, it's very detailed and comprehensive.
>>>
>>> Another alternative is to build the 'development environment'. This
>>>> environment is intended for developers who are working directly on PRs for
>>>> Sugar modules.
>>>
>>>
>>> Yes, I am looking to build the 'development environment', specially the
>>> ASLO server but I am facing some issues. since sphinx is very old and
>>> cannot be compiled (using make) properly. Wanted to know if there is
>>> someone who maintains the ASLO and  can answer this specific query, related
>>> to building ASLO locally and getting started on it
>>>
>>> Thanks,
>>> Jatin Dhankhar
>>>
>>> On Sat, Apr 1, 2017 at 6:31 AM, Tony Anderson < <tony_anderson at usa.net>
>>> tony_anderson at usa.net> wrote:
>>>
>>>> Hi Jatin,
>>>>
>>>> There are two major elements to Sugar. The desktop interface - Sugar
>>>> and the activities. ASLO is a library of these activities. Build only
>>>> applies to Sugar.
>>>>
>>>> For a non-XO version of Sugar, there are two easy choices: SOAS and
>>>> Sugar on Ubuntu. For Ubuntu, install 14.04 or more recent version (I am
>>>> using 16.04) and execute sudo apt-get install sucrose. For SOAS, download
>>>> the image and dd it to a usb stick. It works as a livecd.
>>>>
>>>> Another alternative is to build the 'development environment'. This
>>>> environment is intended for developers who are working directly on PRs for
>>>> Sugar modules.
>>>>
>>>> In deploying Sugar, the only fully supported platform is the XO. The
>>>> Ubuntu Sugar appears not to connect to networks and omits some of the
>>>> essential activities. These are the essential eight: Browse, Record,
>>>> Jukebox, Terminal, Log, Write, Read, and Image Viewer. Several of these
>>>> such as Record provide access to hardware features of the platform such as
>>>> the camera and microphone. Naturally, these are more difficult to support
>>>> on general platforms.
>>>>
>>>> There are two programming environments for Sugar activities: Python and
>>>> Javascript. HelloWorld and HelloWeb are simple examples of activities in
>>>> Python and Javascript, respectively. There is an excellent text available
>>>> for download online:
>>>>
>>>> Make Your Own Sugar Activities!
>>>> By James Simmons
>>>> <http://www.lulu.com/shop/search.ep?contributorId=739770>
>>>>
>>>> Make sure to get the second edition.
>>>> Tony
>>>>
>>>> On 04/01/2017 12:00 AM, <aslo-request at lists.sugarlabs.org>
>>>> aslo-request at lists.sugarlabs.org wrote:
>>>>
>>>> Send ASLO mailing list submissions to
>>>> 	aslo at lists.sugarlabs.org
>>>>
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>> 	http://lists.sugarlabs.org/listinfo/aslo
>>>> or, via email, send a message with subject or body 'help' to
>>>> 	aslo-request at lists.sugarlabs.org
>>>>
>>>> You can reach the person managing the list at
>>>> 	aslo-owner at lists.sugarlabs.org
>>>>
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of ASLO digest..."
>>>>
>>>>
>>>> Today's Topics:
>>>>
>>>>    1. ASLO build and deployment process (Jatin Dhankhar)
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Fri, 31 Mar 2017 16:57:58 +0530
>>>> From: Jatin Dhankhar <dhankhar.jatin at gmail.com> <dhankhar.jatin at gmail.com>
>>>> To: aslo at lists.sugarlabs.org
>>>> Subject: [ASLO] ASLO build and deployment process
>>>> Message-ID:
>>>> 	<CAD+LdAF26TWi9uPP0pPZPTFWm3L5HF3=ubc4_TBY9O8v_e=T1Q at mail.gmail.com> <CAD+LdAF26TWi9uPP0pPZPTFWm3L5HF3=ubc4_TBY9O8v_e=T1Q at mail.gmail.com>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> Hi,
>>>>
>>>> I have few questions about how ASLO is actually build and deployed in
>>>> production. Build process is carried out by using Fabfile, I tried using
>>>>  it and was not successful in building the sphinx ( since version used is
>>>> 0.9.9.rc2 and current series is 2.x).
>>>> Relevant pull request and issue
>>>> PR -> https://github.com/sugarlabs/aslo/pull/2
>>>> Issue -> https://github.com/sugarlabs/aslo/issues/1
>>>>
>>>> I am using Arch Linux and have installed all the necessary dependencies for
>>>> development including mysql and postgres development libraries along with
>>>> common development libraries. If anyone can point on how to successfully
>>>> build the project that would help a lot.
>>>> Some thread points out upgrading to new version of Sphinx but I wanted to
>>>> mirror the current instance.
>>>> Also project mentions something about Remorahttps://wiki.mozilla.org/Update:Remora and wiki says it's no longer
>>>> maintained.
>>>> It quotes
>>>>
>>>>
>>>> Remora is no longer maintained. See AMO:Developers<https://wiki.mozilla.org/AMO:Developers> <https://wiki.mozilla.org/AMO:Developers>.
>>>>
>>>> Also wanted to know more about how ASLO is deployed in production. What
>>>> techniques are used ? What are the pain points that need to be addressed
>>>> and tips on how to get started with it. If anyone is familiar with ASLO or
>>>> a long time maintainer, can they point out on how to reproduce a successful
>>>> build of ASLO (a documentation on how to run would be awesome)
>>>>
>>>> Thanks,
>>>> Jatin Dhankhar
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL: <http://lists.sugarlabs.org/archive/aslo/attachments/20170331/12204ccc/attachment-0001.html> <http://lists.sugarlabs.org/archive/aslo/attachments/20170331/12204ccc/attachment-0001.html>
>>>>
>>>> ------------------------------
>>>>
>>>> Subject: Digest Footer
>>>>
>>>> _______________________________________________
>>>> ASLO mailing listASLO at lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/aslo
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> End of ASLO Digest, Vol 84, Issue 1
>>>> ***********************************
>>>>
>>>> _______________________________________________ ASLO mailing list
>>>> ASLO at lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/aslo
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/aslo/attachments/20170405/6c71478a/attachment-0001.html>