Apparently, I misspoke. The problem I was referring to was access to
ASLO not github. Currently, as you point out, developers only have
ability to update their own activities. The GitHub system seems more
flexible.
Alphabetizing works the same only if the naming is uniform. Currently
most of the activities added by the GCI contributors are some-activity
not activity-some.
I agree on separating the core repos from the activity repos. Ignacio
suggested http://github.com/sugar-activities as the organization for the
activities. This would facilitate release of Sugar limiting it to the
eight 'unerasable' activities: Browse, Record, Log, Terminal, Chat,
Jukebox, Write, and ImageViewer. Other activities could be added to
Sugar as desired by deployers (such as James Cameron). Another benefit
to this approach is that activity developers do not need rights to the
Sugarlabs repositories.
Having separate repositories for gtk2 and gtk3 is would be justified if
they require separate maintenance. The other activities more ported to
gtk3 with incremented version numbers. This seems reasonable since the
intent was to deliver the same functionality and to be the current
version of that activity.
Tony
On 04/21/2017 08:10 PM, Walter Bender wrote:
>
> On Apr 20, 2017 10:45 PM, "Tony Anderson" <tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>> wrote:
>
> I wish it were so easy.
>
> Currently turtleblocks has been ported to the github repository as
> activity-turtleart-gtk2 and activity-turtleart-gtk3 (no
> activity-turtleart-web so far).
> Personally, I would prefer to see this as turtleblocks
> (turtleblocks-activity). Putting activity after the name helps
> with alphabetizing. It seems that we have had the confusion
> between turtleblocks and turtleart forever. My current
> understanding is that there is one activity named turtleblocks and
> no second simplified version named turtleart.
>
>
> I will change the name of the TA repository... it has been on my
> to-do list for a while. (I created it at a time when we didn't yet
> settle on activity-activity name vs activity name-activity. Both would
> sort alphabetically the same, FWIW. And the former schema, which I was
> advocating for, makes it easier to separate out the core Sugar repos.
> But I defer to my fellow maintainers.)
>
> The bigger issue with Ignacio's suggestion is that we will lose all of
> the git history if we simply make repos from the .xo bundles. This
> will be a nightmare going forward. We really need to find the source
> repos if at all possible.
>
>
> I gather there is a permissions issue in creating new repositories
> that requires this procedure.
>
>
> There are about 20 developers who have permission to directly create
> repos in the sugarlabs project on github. Not sure why this is a problem.
>
> -walter
>
>
> Tony
>
> On 04/21/2017 09:51 AM, Ignacio Rodríguez wrote:
>
> Hi everyone.
>
> It is a one-time effort per activity to "transfer" it to
> sugarlabs.
>
> I suggest creating a script to download all XO files from ASLO and
> create the github repos under github.com/sugarlabs
> <http://github.com/sugarlabs>, ie:
> turtleblocks-activity
>
> or maybe turtleblocks-aslo this way we can move all activities to
> GitHub, we can later contact mantainers or so.
>
> (I´m not following the whole thread, just saying this).
>
> Also, not sure if there is a limit of repositories by organization
>
>
> Ignacio
>
> On 4/20/17, Tony Anderson <tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>> wrote:
>
> Agreed. I copy the repository from some-activity-master to
> some.activity in /home/olpc/Activities on an XO. It then
> runs in Sugar
> as an activity.
>
> I assume setup.py is the standard way to make a bundle and
> includes
> various checks. At present it checks that the repository
> is git enabled
> apparently to replace the need for a manifest. This could
> be a good
> place to put other checks, e.g. a complete activity,info.
>
> Tony
>
> On 04/21/2017 08:10 AM, Walter Bender wrote:
>
>
> On Thu, Apr 20, 2017 at 8:07 PM, Tony Anderson
> <tony_anderson at usa.net <mailto:tony_anderson at usa.net>
> <mailto:tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>>> wrote:
>
> Hi Walter,
>
> The git repo is not an xo bundle. The bundle
> needs to be built by
> setup.py. Attempts to run the repo return an
> error: activity
> directory name must end in activity.
>
>
> You can name the git repo anything you want when you
> clone... I do it
> all the time to save the trouble of making the bundle
> each time when
> debugging. What am I missing?
>
>
> Apparently developers have permission to add an
> xo bundle, but do
> not have permission to update ASLO so that it
> shows that bundle.
>
> Tony
>
> On 04/21/2017 07:42 AM, Walter Bender wrote:
>
>
> On Thu, Apr 20, 2017 at 7:35 PM, Tony Anderson
> <tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>
> <mailto:tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>>> wrote:
>
> Hi, Walter
>
> It is wonderful to see a discussion on
> technical matters
> concerning Sugar.
>
> Assuming we plan to handle development
> and maintenance of
> activities through GitHub, then the
> 'publishing' of an
> activity should be a simple copy of the
> xo bundle to
> download.sugarlabs.org/activities
> <http://download.sugarlabs.org/activities>
> <http://download.sugarlabs.org/activities
> <http://download.sugarlabs.org/activities>> and an
> update so
> that version is the one shown by ASLO.
> The developer hub and
> its authentication would no longer be needed.
>
> For the activities not now in GitHub, as
> I understand it, the
> activity should first be copied to a
> personal repository on
> github and then
> the systems mailing list be notified to
> make the transfer.
> Your steps 2-4 should be done before the
> transfer.
>
> The word tedious applies also to the
> process of testing the
> activities.
>
> 1. Download the activity zip file from
> GitHub (made necessary
> as a download from ASLO was often not the
> right version).
> 2. Use setup.py to generate the xo bundle
> (python setup.py
> dist_xo).
> 3. Some activities did not have a
> setup.py or it failed. In
> this case cp -r some-activity-master
> /home/tony/Activities/some.ac
> <http://some.ac>tivity
>
>
> Why not just download the git repo directly
> into ~/Activities?
> That should work.
>
>
> 4. Run the activity
> 5. If failed to start, debug with the log
> 6. If possible fix, and run again
> 7. Go to GitHub and post issues reporting
> the problems
>
> I suspect this could be automated by a
> python script assuming
> that an activity which starts
> successfully is working. Such a
> script could 'lint' check the activity
> and activity.info <http://activity.info>
> <http://activity.info> to see that it
> meets our standards.
> One problem will be to arrange tests on
> four models of XO
> plus any other supported platforms
> (Ubuntu, RPi, ...).
>
> Tony
>
>
>
> On 04/20/2017 08:22 PM, Walter Bender wrote:
>
> On Thu, Apr 20, 2017 at 3:45 AM, Tony
> Anderson
> <tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>
> <mailto:tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>>> wrote:
>
> Hi, Walter
>
> I am new to this. I am registered
> as a member. However,
> it may take an 'owner'. I assume
> that the process you
> describe is how we expect our
> users to submit new
> activities. However, this may
> become a distraction for
> someone to keep having to move
> activities to Sugarlabs.
>
>
> It is a one-time effort per activity
> to "transfer" it to
> sugarlabs.
>
> What is tedious the process I am
> going through right now to
> just update the version numbers of an
> activity:
>
> 1. clone the activity
> 2. update the version number
> 3. update NEWS with all of the commit
> info since the last
> version update
> 4. often it is necessary to update
> the repo path as it was
> not changed when the activity was
> transfered
> 5. make a PR
> 6, wait for someone to merge the PR
> 7. once the PR is merged, pull the
> updated repo
> 8. use setup.py to create new .xo and
> .tar bundles
>
> Here is where things break down:
>
> 9. use admin privileges on ASLO to
> add myself to the activity
>
> 10. upload a new version of the activity
> 11. scp the tar file to downloads
>
> And here:
>
> 12. add a tag with the new version
> number to the repo on
> GH/sugarlabs
>
> Would be great to have some scripts
> that do most of 1-8.
> Not sure about how to handle 9 properly.
> Would be great to automate 10-11.
> Not sure the proper protocol for 12.
>
> Finally, what is the protocol for
> renaming repos in
> GH/sugarlabs ? I renamed portfolio to
> portfolio-activity for
> consistency. Lots of other activities
> should be renamed. But
> I don't know how to do except
> unilaterally,
>
> regards.
>
> -walter
>
>
>
> Tony
>
> On 04/20/2017 09:26 AM, Walter
> Bender wrote:
>
> On Wed, Apr 19, 2017 at 9:09
> PM, Tony Anderson
> <tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>
> <mailto:tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>>>
> wrote:
>
> I get the following
> messages when trying to create
> a new repository in
> sugarlabs:
>
> You don’t appear to have
> permission to create
> repositories for this
> organization. Sorry about that.
>
>
> That is by design. Only
> members can create repositories
> on the project.
>
> Quoting from
>
> https://github.com/sugarlabs/sugar-docs/blob/master/contributing.md
> <https://github.com/sugarlabs/sugar-docs/blob/master/contributing.md>
> <http://ting.md>
>
> "For new activities, make a
> new repository in your
> GitHub account, put the
> source code in it, then ask the
> systems@ list to move it to
> the sugarlabs organisation."
>
> You can also of course ask to
> join the sugarlabs
> project on GitHub.
>
> -walter
>
>
> Tony
>
> On 04/20/2017 03:56 AM,
> Samuel Cantero wrote:
>
> On Wed, Apr 19, 2017
> at 1:40 AM, Tony Anderson
>
> <tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>
>
> <mailto:tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>>> wrote:
>
> Hi Walter
>
> We haven't heard
> from Sam C.
>
>
> Hi everyone! I'm
> sorry I haven't replied before. I
> have been very busy
> these days. I don't know much
> about ASLO
> architecture. I just have helped to
> keep it working.
> Aleksey is the correct guy here.
>
>
> I am thinking
> that rather than keep the
> metadata
> regarding Sugar activities, it might
> be better to
> include it in activity.info
> <http://activity.info>
>
> <http://activity.info> (e.g. developers,
> summary,
> description, what works, release
> notes). This
> would enable ASLO to generate its
> screens from the
> bundle.
>
> Jatin now has a
> working minimal prototype of
> the Django
> version. It would be helpful if it
> were on the Sugar
> servers supporting ASLO.
>
>
> We can configure a
> dev environment in our server
> and enable CI. It
> would be good to keep main repo
> in GitHub, inside
> sugarlabs organization. This
> will give us more
> chance to encourage other people
> to help. Where is the
> prototype right now? I would
> like to take a look.
>
>
> I would like to
> add some activities from ASLO
> to the github
> repository. Currently I am a
> 'member'. Is that
> sufficient to enable adding
> a new activity?
>
>
> Try and tell me.
>
>
> I have posted
> issues to each of the activities
> I tested on the
> github/sugarlabs. Several of
> the activities
> can be fixed by simple code
> changes. More
> importantly, some order is
> needed in the
> assignment of version numbers
> and releasing the
> updated activities to ASLO.
> While I am a
> developer on ASLO, I don't have
> the ability to
> release new versions of
> activities in
> general.
>
>
> I would
> appreciate your help in setting up the
> authorizations
> needed.
>
>
> Thanks,
>
> Tony
>
>
>
> On 04/13/2017
> 01:40 AM, Walter Bender wrote:
>
> Let's try to
> get Sam C., who currently
> maintains
> ASLO into the loop. I think he'll
> have lots of
> good advice for us.
>
> regards.
>
> -walter
>
> On Wed, Apr
> 12, 2017 at 1:14 PM, Jatin
> Dhankhar
> <dhankhar.jatin at gmail.com
> <mailto:dhankhar.jatin at gmail.com>
>
> <mailto:dhankhar.jatin at gmail.com
> <mailto:dhankhar.jatin at gmail.com>>> wrote:
>
> Hi,
>
> I
> think we need to agree on the use
> of
> IRC. If you want to communicate
> with
> members of the community, you
> must
> go where they are (#sugar). If
> you
> want a one-to-one meeting on IRC
> with
> me, I would suggest
> #sugar-newbies. It is normally
>
> dormant but works well and saves a
> log
> for later review. It worked well
> for
> meetings with Utkarsh Tiwari
>
> during last year's GSOC.
>
> Sure,
> whatever works :). What is your IRC
> nickname ?
>
> There
> are two things that you will
> need
> to have local to the django
>
> project. First is the directory
> download.sugarlabs.org
> <http://download.sugarlabs.org>
>
> <http://download.sugarlabs.org/
> <http://download.sugarlabs.org/>>
> which
> has
> the
> Sugar activity bundles
>
> Do I need
> to mirror the whole
>
> setup/directory ?
>
> When
> talking about scraping you probably
> meant
> http://activities.sugarlabs.org
> <http://activities.sugarlabs.org>
> instead
> of
> http://download.sugarlabs.org/,
> right ?
> Also for
> scraping, Scrapy
>
> <https://scrapy.org/> seems to more
> popular
> than beautifulsoup ?
>
> Also a
> big thanks for including Walter in
> the
> discussion :D
>
> - Jatin
> Dhankhar
>
> On Wed,
> Apr 12, 2017 at 6:30 AM, Tony
> Anderson
> <tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>
>
> <mailto:tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>>>
> wrote:
>
> Hi, Jatin
>
> I
> think we need to agree on the use
> of
> IRC. If you want to communicate
> with
> members of the community, you
> must
> go where they are (#sugar). If
> you
> want a one-to-one meeting on IRC
> with
> me, I would suggest
> #sugar-newbies. It is normally
>
> dormant but works well and saves a
> log
> for later review. It worked well
> for
> meetings with Utkarsh Tiwari
>
> during last year's GSOC.
>
> There
> are two things that you will
> need
> to have local to the django
>
> project. First is the directory
> download.sugarlabs.org
> <http://download.sugarlabs.org>
>
> <http://download.sugarlabs.org
> <http://download.sugarlabs.org>> which
> has
> the Sugar activity bundles. The
>
> second is the 'metadata' in the mysql
> db.
> For scraping, I would recommend
>
> BeautifulSoup (bs4). The trick will
> be to
> decide what data we want to
>
> capture and add to the json.
>
> The
> json fields in activities.json
> are
> ones I chose for the minimal
>
> system. You may want to include other
>
> information such as the number of
>
> downloads, which collections (should
> be
> entered as tags in a tag-field)
> and
> so on. One item I have referred
> to as
> flags (I marked some as X but
> don't
> remember what that meant, oh
>
> well). The intent is to record the
>
> platforms where the activity works.
> We
> also should provide links to the
>
> homepage, repository page, and update
> page
> (whatever that is). I think if
> you
> have a working scrape tool, the
> data
> it collects can be expanded as
>
> needed (assuming the tool runs in a
>
> reasonable time).
>
>
> Naturally, it would be easier if you
> have
> access to the db directly.
>
> Tony
>
>
> On
> 04/12/2017 01:40 AM, Jatin
>
> Dhankhar wrote:
>
>
> One thing you could look at. On
> activities.sugarlabs,org, can
>
> you determine from Remora where
>
> the metadata is stored? I
> assume
>
> a db. Currently I am
> thinking to
>
> use BeautifulSoup to scrape the
>
> site to get that data, but it
>
> would be much easier to access
>
> the data directly.
>
>
> As per wiki
>
> https://wiki.mozilla.org/Update:Remora_Server_Requirements#SVN.2C_DB_and_app_config
> <https://wiki.mozilla.org/Update:Remora_Server_Requirements#SVN.2C_DB_and_app_config>
> data
>
> is stored in mysql database.
> I don't
>
> have access to the production
> server
>
> where ASLO is currently running,
>
> following file
>
> https://github.com/sugarlabs/aslo/blob/master/aslo/db-update.sh#L9
> <https://github.com/sugarlabs/aslo/blob/master/aslo/db-update.sh#L9>
> confirms
>
> that data is stored in a
> mysql db.
>
> However it would be
> interesting and
>
> fun to scrape the data from live
>
> site. I would do that.
>
>
> Thanks will poke around the code,
>
> looks to me it's a django app
> and I
>
> have to mount it on my django
>
> project, thanks :)
>
>
> If you are talking about IRC as
>
> a place to meet Sugar community
> members, use the freenode
>
> #sugar. This is probably most
>
> active from 8-17 EST (UTC-5). I
>
> am currently in the Philippines
>
> which is UTC+ 7.
>
>
>
> Yes, tried that.
> https://gitter.im fits in
> naturally
>
> with Github (really sorry for
>
> suggesting a new mode of
> communication everyday) 😅
>
> -
> Jatin Dhankhar
>
>
>
> On Tue, Apr 11, 2017 at 6:14 AM,
>
> Tony Anderson
> <tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>
>
> <mailto:tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>>>
> wrote:
>
>
> If you are talking about IRC as
>
> a place to meet Sugar community
> members, use the freenode
>
> #sugar. This is probably most
>
> active from 8-17 EST (UTC-5). I
>
> am currently in the Philippines
>
> which is UTC+ 7.
>
> Localization of Python
> activities is done by Pootle,
>
> when implemented by the
> developer. The developer does
> something like the following:
>
> from gettext import
>
> gettext as _
>
> self.copy.set_tooltip(_('Copy'))
>
>
> In this way, all text displayed
>
> is taken from a po file
> based on
>
> the locale (e.g. en.po or
>
> hi.po). This is a
> simplification
>
> as the actual file is
> compressed: en.mo, hi.mo. These
>
> files are in the activity
>
> bundle. The detail is that when
>
> a new version is released,
> there
>
> is a master file: Paint.pot
> from
>
> which the local language files
>
> are built. This needs to be
> submitted to
> translate.sugarlabs.org
> <http://translate.sugarlabs.org>
>
>
> <http://translate.sugarlabs.org
> <http://translate.sugarlabs.org>>
>
> which maintains a copy.
> However,
>
> then the localized version
> needs
>
> to be added back to the bundle.
> However, the localizations can
>
> take months for 100
> languages so
>
> how synchronize the po
> directory
>
> with the activity release is
> difficult.
>
>
> The sugar3 vs sugar issue is
> decided. The community wants to
>
> move to sugar3 (gtk3). The
>
> problem is that less that
> 20% of
>
> the activities have been
> converted.
>
> The ones that have been
> converted are low hanging fruit.
>
> The unconverted ones may
> require
> intensive work (gimp which
> developed gtk originally has not
>
> made the conversion).
>
>
> One thing you could look at. On
> activities.sugarlabs,org, can
>
> you determine from Remora where
>
> the metadata is stored? I
> assume
>
> a db. Currently I am
> thinking to
>
> use BeautifulSoup to scrape the
>
> site to get that data, but it
>
> would be much easier to access
>
> the data directly.
>
> Yesterday afternoon, the ISP
> restored service. Last time it
>
> died after two days, but I am
>
> keeping my fingers crossed.
> I am
> attaching the django stuff.
>
>
> Tony
>
>
>
> On 04/11/2017 01:36 AM, Jatin
> Dhankhar wrote:
>
>
> Hi Tony,
>
> Normally, we use
> http://chat.sugarlabs.orgor
> on freenode: sugar-meeting
> or sugar-newbies. These are
> logged sites so that there
> is a record. The second is
> more appropriate since
> sugar-meeting is used for
> SLOB meetings and the like.
> The real problem with IRC
> is time zones. Email has
> the advantage that either
> party can send or receive
> at any time. Last year with
>
> a GSOC mentee
> we used
> sugar-newbies by arranging
>
> a specific
> meeting time in
> advance.
>
>
> Yes, that is
> correct, main
>
> issue in
> communication barrier
>
> is due to timezone
> issues.
>
> Since most of the
> people are
> familiar and are available on
>
> IRC, it's seems to
> be the
> primary channel of
> communication along with
> mailing lists and email. But
>
> since you said we
> can use
> anything else, giving Slack a
>
> try won't hurt (if
> issue is
>
> about not using
> closed source
> software then IRC is fine, or
>
> we can try Mattermost
>
>
> <https://about.mattermost.com/
> <https://about.mattermost.com/>>).
>
> Another part of the
> process is how to update
>
>
> 'translate.sugarlabs.org
> <http://translate.sugarlabs.org>
>
> <http://translate.sugarlabs.org/
> <http://translate.sugarlabs.org/>>'
> with the corresponding POT
> file to enable
> localization. We can get
> help from Chris Leonard on
> this.
>
>
>
> I am not aware on how
> localization works. Do we
> need
>
> to download
> relevant files and
> bundle them with the acitvity
> before making it available on
>
> ASLO ?
>
>
> I have my
> Django version
> available - but the
> internet problems here are
> still unresolved. The
> technician is supposed to
> make another visit today to
> see what is wrong with our
> connection. Let me know if
> and when you think this
> will be useful to you.
>
>
> Let me know when your
> connection is stable and I
>
> would start.
> What are the things you need
>
> me to do in the
> meantime ?
>
> One open issue is sugar3 vs
> sugar. Currently two
> versions of Sugar are
> released. The sugar version
> supports gtk while sugar3
> supports gtk3.
> Unfortunately, gtk3 was
> developed to be totally
> incompatible with gtk. For
> example, incorporation of
> one gtk3 feature requires
> that all direct and
> indirect references to gtk
> be removed or the activity
> will throw an exception.
> Several of the gtk3
> conversions failed to meet
> this test and so fail. The
> issue is whether curated
> activities be limited to
> ones converted to gtk3. The
> positive is that Sugar
> could revert to releasing
> and maintaining only a
> single version. The
> downside is that 100 or
> more activities will no
> longer be available.
> Specifically, in our
> implementation of ASLO, we
> need to show which versions
> of an activity work on
> which versions of Sugar
> (e.g. i86, arm, amd64,
> sugar or sugar3, and so
> on). We also need to show
> which ones support
> localization. There are
> many English activities and
> many Spanish activities
> that make no provision for
> localization. Luckily there
> are many that have no
> language component.
> However, for many of these,
> some kind of help is needed
> to convey the way the
> activity works.
>
>
>
> Some people believe
> GTK3 is
> slightly better
>
> <https://www.reddit.com/r/linux/comments/3e3q8n/is_there_a_technical_reason_why_gtk3_is_better/
> <https://www.reddit.com/r/linux/comments/3e3q8n/is_there_a_technical_reason_why_gtk3_is_better/>>
> and
>
> I think GTK3 will
> stay but that
> should be asked in community
>
> and voted upon and
> taking in
> considerations cost of
> development and porting,
> only a
> discussion will help in
> this one.
>
> You are wading into a deep
> and vast body of water!
>
>
> As long as I have
> something to
>
> hold onto, I will
> not drown 😅
>
> Thanks,
>
> Jatin Dhankhar
>
>
> On Mon, Apr 10,
> 2017 at 9:11
>
> AM, Tony Anderson
>
>
> <tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>
> <mailto:tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>>>
> wrote:
>
> Hi, Jatin
>
> Normally, we use
> http://chat.sugarlabs.org
> or on freenode:
> sugar-meeting or
> sugar-newbies. These are
> logged sites so that there
> is a record. The second is
> more appropriate since
> sugar-meeting is used for
> SLOB meetings and the like.
> The real problem with IRC
> is time zones. Email has
> the advantage that either
> party can send or receive
> at any time. Last year with
>
> a GSOC mentee
> we used
> sugar-newbies by arranging
>
> a specific
> meeting time in
> advance.
>
>
> I haven't heard
> from
> Walter, but my preference
> would be to use the
> Sugarlabs server since the
> content is largely already
> there and it would be
> easier to make it the
> official site if that were
> decided. So in the short
> run, I think you should do
> whatever is best for your
> own development process.
>
>
> I am not sure
> how CI fits
> into this. If the activity
> development is done on
> GitHub, then the deployment
> model is to run setup.py to
> create an xo bundle and
> then copy that bundle to
> the appropriate location in
> the
> download.sugarlabs.org
> <http://download.sugarlabs.org>
>
> <http://download.sugarlabs.org>
> tree. Assuming the update
> results from a PR, the
> deployer would need to
> update the activity
> information on ASLO
> appropriately. However,
> that process depends on
> where that data (metadata)
> is stored. Another part of
> the process is how to
> update
>
>
> 'translate.sugarlabs.org
> <http://translate.sugarlabs.org>
>
> <http://translate.sugarlabs.org
> <http://translate.sugarlabs.org>>'
> with the corresponding POT
> file to enable
> localization. We can get
> help from Chris Leonard on
> this.
>
>
> I have my
> Django version
> available - but the
> internet problems here are
> still unresolved. The
> technician is supposed to
> make another visit today to
> see what is wrong with our
> connection. Let me know if
> and when you think this
> will be useful to you.
>
>
> I have now
> tested most of
> the activities (~400). I
> was optimistic in the
> number that work out of the
> box. However, a part of
> this is running them in the
> Ubuntu version of Sugar
> (amd64). There are many
> activities which launch
> object code (mostly c)
> which is dependent on the
> architecture. I am now
> trying to repeat the tests
> on an XO-1.75. One issue on
> Ubuntu is that many
> activities assume a
> 1200x900 screen and so on a
> 1024X768 screen overflow.
> This makes some of the
> games unusable since part
> of the controls are off the
> screen. Because of the
> internet problems, the
> untested activities tend to
> be new ones since I was
> using my local repository
> which is a snapshot taken
> several months ago. The
> other group are the
> GCompris activities (about
> 70).
>
> My intent is to build a
> 'curated' repository of
> activities known to work
> and be usable on the XO and
> on Ubuntu (or such other
> platform that Sugar may
> choose to support). Most of
> the currently not work
> activities have software
> dependencies no longer
> included in the current
> Sugar release. So the
> curated library will grow
> as activities are repaired
> over time.
>
> One open issue is sugar3 vs
> sugar. Currently two
> versions of Sugar are
> released. The sugar version
> supports gtk while sugar3
> supports gtk3.
> Unfortunately, gtk3 was
> developed to be totally
> incompatible with gtk. For
> example, incorporation of
> one gtk3 feature requires
> that all direct and
> indirect references to gtk
> be removed or the activity
> will throw an exception.
> Several of the gtk3
> conversions failed to meet
> this test and so fail. The
> issue is whether curated
> activities be limited to
> ones converted to gtk3. The
> positive is that Sugar
> could revert to releasing
> and maintaining only a
> single version. The
> downside is that 100 or
> more activities will no
> longer be available.
> Specifically, in our
> implementation of ASLO, we
> need to show which versions
> of an activity work on
> which versions of Sugar
> (e.g. i86, arm, amd64,
> sugar or sugar3, and so
> on). We also need to show
> which ones support
> localization. There are
> many English activities and
> many Spanish activities
> that make no provision for
> localization. Luckily there
> are many that have no
> language component.
> However, for many of these,
> some kind of help is needed
> to convey the way the
> activity works.
>
> You are wading into a deep
> and vast body of water!
>
> Tony
>
>
> On 04/10/2017 12:00 AM,
> Jatin Dhankhar wrote:
>
> Hi,
> Sorry for the delay. I
> went through the polls
> tutorials and I think
> I am
> getting hang of Django. I
> have one query that
> is out
> of context, what is your
> IRC setup ? IRC doesn't
> allow message to be
> delivered or stored once
> either party is offline,
> people login through a
> external server for IRC's
> to maintain their
> availability in a
> channel.
> May I suggest something
> like Slack or Flock for
> communication. IRC is
> good
> for quick and fast
> connection but Slack and
> alternatives allow easy
> communication. (Just a
> suggestion, though)
>
> Should I deploy the same
> polls app on DigitalOcean
> along with CI
> pipeline and
> branching model in the
> meantime with code hosted
> on Github ?
>
> ...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/aslo/attachments/20170422/8750aa16/attachment-0001.html>