[Sugar-devel] [IAEP] (Goals and Mission) with Microsoft in it?

[Tony Anderson]

On 05/17/2017 03:11 PM, James Cameron wrote:
> On Wed, May 17, 2017 at 02:44:10PM +0800, Tony Anderson wrote:
>> The proposal is online at
>> https://summerofcode.withgoogle.com/organizations.  Click on Sugar
>> Labs. There are 9 accepted proposals, each with a pdf description.
> No, they are not accessible.  When you click on the link you get a
> prompt "Sign in with your Google Account".  Paywalled.  Closed doors.
Sorry, I sent a copy of the pdf by private email. No secrecy, just 
bandwidth to send the pdf to the list.

>> The project intends to refresh ASLO using Django. Django is a
>> 'fusion' framework involving Python plus templates using HTML5. It
>> is currently maintained and in widespread use. The concern expressed
>> when ASLO crashed was that it was based on an obsolete version of
>> PhP and that there was no one in the community who was currently
>> familiar with the implementation.  Using Python and HTML5 in a
>> well-known framework should make it easier to maintain.
> No, it won't help.  If there were a maintainer of ASLO, they would
> have picked up the necessary PHP skills in a jiffy, when faced with a
> problem and a desire to fix it.
>
> Instead, you're proposing to use a framework that hasn't been used by
> Sugar Labs.  By a volunteer we won't necessarily see again after GSoC
> is over.  Does not sound sustainable.
I hope to have help in reviewing the documentation on github to ensure 
it is adequate. I don't see this as a very complex task.
>
> For what it is worth, we use Django for https://activation.laptop.org/
> and I'm very familiar with it.  The style of Python that Django
> requires is entirely different to Sugar and activities.  Not that we
> have any active activity coders lately.
Not intended for use by activity or sugar developers. Maintenance will 
be needed by server administrators (we don't have very many of those 
either).
>
> The concern that it was an obsolete version of PHP was specious; there
> are adequate tools in the PHP community for porting to new versions,
> and I've done it several times with PHP web applications I've managed.
>
>> The community has chosen to move the activity repository to
>> github/sugarlabs.
> No, it hasn't.  I've not seen consultation on that.  Do show me behind
> what closed doors it happened this time?
This is one of the problems with attempting to work with Sugar Labs. We 
don't appear to be on the same page.
This is a matter that Walter has pressed strongly in recent GSOC. Two 
years ago this was the major focus of GCI.
Personally, I see no problem with the current system if it were kept up 
to date. For example, I have access to update only the
activities which I contributed. This is too limited to maintain a 
library of over 600 activities when most of the original contributors 
have moved on.
Heaven help us that this matter becomes a SLOBS motion.
>
>> The apparent goal is to make the activities more maintainable by the
>> community over the previous individual contributor model. This
>> implies that the current 'Developer Hub' part of the site be
>> replaced by a github process.
>>
>> The connection between github and ASLO in this new model is that
>> someone with appropriate permissions will review a submitted new
>> activity version and publish it to ASLO (setup.py dist_xo and
>> uploading to download.sugarlabs.org/activities).
>>
>> The activity.info file could be expanded to include the 'metadata'
>> now stored on ASLO (developer, summary, description, works with, and
>> links to the activity repository on github/sugarlabs).
> Some of this expansion of the .info file format was done years ago,
> and I've been maintaining it since, so I'm surprised you mention it;
> have you checked the format and metadata recently?
Yes. A significant number of activity.info files don't have bundle_id or 
exec.
>
>> This would facilitate maintenance of this information by the
>> developer/maintainer by submitting changes to activity.info to git
>> and, perhaps, eliminate dependency on a database.
>>
>> One hope is that the project design will support easy replication of
>> ASLO on school servers for deployments without access to the
>> internet.
> Where's the engagement with a school server provider?  Sounds like a
> forlorn hope if there's nobody going to do that.
This has not been supported by xsce. However, I have deployed school 
servers for several years with a snapshot of ASLO.
>
>> There may be impact on the software update procedure but at the
>> moment that is also outside the scope of this project.
> So it's goodbye to another useful function.
I am sure we would disagree on its usefulness, but if someone is 
familiar with it they could help us continue to meet its requirements. 
On the school server, the way this works is that it notifies XO users 
when there is a new activity version. This is not useful because, in 
general,  the school server doesn't have these activities and is not 
connected to the internet.
>
>> Extending the project to School Network is also outside the scope.
>>
>> The next step in the project with support from Sam Cantaro is to
>> install a working model on Sunjammer as activities2.sugarlabs.org so
>> that everyone can see it and provide input. The project will be
>> opened on github/sugarlabs.
>>
>> This phase of GSOC is always a little slow as the participants are
>> in year-end exam cycles.
>>
>> Tony