[IAEP] [Sugar-devel] New ASLO Project Definition

[Samuel Cantero]

Thanks all for the comments. Here are my replies:

On Thu, May 18, 2017 at 9:19 PM, Tony Anderson <tony_anderson at usa.net>
 wrote:
>Hi Sam,
>
>Thanks for the proposal. Naturally this raises the question of the
relationship >between your ASLOv3 and the GSOC project. Do you see two
parallel >implementations or a merger of the two projects?

I don't understand your question. It's a proposal for the new ASLO
implementation. One of the goals defined in Jatin's project. or is there
another direction defined for this I am not aware of?

On Fri, May 19, 2017 at 3:04 AM, James Cameron <quozl at laptop.org> wrote:
>No.  I disagree with the conclusion.

I'm not saying I'm right. It's my point of view and I'm glad you have
shared yours. Yes, lack of maintainers is a big issue and I don't expect
the proposed design will fix all issues we have.

> The argument that ASLO is out of date because of there being two
> places to update information ... is specious.  Besides, "two" is
> wrong; there is a third place critical for downstream packaging;
> download.sugarlabs.org.

download.sugarlabs.org simply list the activities (xo files) stored at
files/ folder registered in ASLO. It's a must the sync between ASLO and
download.

>My prediction is that this new effort is just going to make things
>worse.  Few of you speaking in the debate are an activity maintainer
>or developer.  You risk making a tool that nobody will use.

I do not plan to rebuild "the same" ASLO just with a new
language/framework. I'm not interested on that. I have had hard time
finding someone to support or upgrade cakePHP (or other components) in
current ASLO. I didn't see much people helping me last time when it got
broken in server/OS update. So we also risk having a tool (current ASLO)
that nobody will maintain.

We need to fix this issue. We have two options: build a new version but
according to our reality or try to upgrade all components in current ASLO
which does not seem too appealing to developers. It's hard to get
contributors for this codebase.

>It is my job to review activities before they are built into an image;
>checking for malicious code, correct licensing, and correct function.

That's my point about removing the moderation queue. The image builders
will ALWAYS check the activities before they are built into an image.

>Nobody has asked me or added me to moderators queue.  Why not?  ;-)

I didn't know you were not a moderator. Can someone with admin rights add
to James?

> So just to clarify, you are removing from the activity maintainers the
> right and duty to run "python setup.py dist_xo", and "python setup.py
> dist_source", and you are _trusting_ the activity maintainers not to
> place anything in setup.py to subvert or take control of your server?

I was thinking to run this step inside a non privileged container but ideas
are welcome.

> There will be activities that cannot be processed in this way; such as
> the Wikipedia activity.

I'm aware that might be corner cases. That is the reason why it's a draft.

> There will be activities from maintainers who won't engage in this new
> process; how will those activities be welcomed?

They have now the chance to speak up.

> I've no issues with the remainder of the proposal.  Good design.

Thanks. But I don't understand how we should proceed. It looks like we all
are in different tracks.

> I don't think the user base is large enough for an image building web
> service.

Agree and image building need a lot of testing.

On Fri, May 19, 2017 at 5:51 AM, Jatin Dhankhar <dhankhar.jatin at gmail.com>
 wrote:
> My main query is, how we will accomplish moderation and publishing
> to ASLO using Github as a tool ? I might be wrong about the whole
> moderation thing but a healthy discussion will hopefully lead us in
> the right direction.

I think we don't need moderation nor approval. We want to simplify. Please,
you can test current workflow in ASLO to understand why I say simplify.

On Fri, May 19, 2017 at 6:13 AM, Tony Anderson <tony_anderson at usa.net>
 wrote:
>So I see this three-month project as providing a new implementation of the
>distribution function of ASLO,  while support for activity developers and
>maintainers moves to github.

what you mean with a new implementation of the distribution function of
ASLO?

On Fri, May 19, 2017 at 6:31 AM, James Cameron <quozl at laptop.org> wrote:
> I agree.  Django apps are easily internationalised.
+1

> We already have patch review; much better moderation or approval than
> we had before.
+1

> Let's drop the moderation and approval requirement.  Leave it to the
> image builders if they want to go further.  Speaking as an image
> builder.
+1


On Fri, May 19, 2017 at 10:42 AM, Laura Vargas <laura at somosazucar.org>
wrote:

> Thank you Samuel and Walter for share,
>
> I don't understand all the technicalities yet. I try to follow and learn
> :D
>
> I agree with Chris Leonard, we should *prioritize facilitation of the
> localization and internationalization (translations) process and tools*.
>
> There are few workflows that involve so much *international collective
> exchange* and efforts and this is therefore a cultural treasure and a
> vital component of our relationships in the Sugar Labs Community.
>
> In Perú for example, we support the official translation manual to native
> languages of Sugar published in a collaborative relationship with the
> community and the Deployment Administrators.
>
> http://pe.sugarlabs.org/ir/Manual%20de%20Traducci%C3%B3n%20de%20Sugar
>
> We'll continue to do our best effort to it updated if there are
> modifications to the upstream process.
>
> Tons of good energy for the team!
>
> Regards,
>
>
>  Laura V
>
> 2017-05-19 5:31 GMT-05:00 James Cameron <quozl at laptop.org>:
>
>> On Fri, May 19, 2017 at 03:21:03PM +0530, Jatin Dhankhar wrote:
>> > Hello Chris,
>>
>> Please continue to CC sugar-devel at lists.sugarlabs.org for developers.
>>
>> >     Welcome to the Sugar Labs community, When reworking ASLO (a very
>> >     valuable project), please do keep internationalization (i18n) and
>> >     localization (L10n) in mind.  You may or may not know that we do
>> host
>> >     PO files for L10n of NewASLO on our Pootle translation server:
>> >     [1]https://translate.sugarlabs.org/projects/NewAslo/
>> >
>> > Yes, Tony discussed the same points regarding i18n with me earlier on
>> email.
>> >
>> >     I think you are familiar with Pootle. The trick with Django is that
>> the
>> >     display of strings is indirect.
>> >
>> > Pootle is built upon Django, so it should be readily available and easy
>> to
>> > plug.
>>
>> I agree.  Django apps are easily internationalised.
>>
>> >     Sam Cantaro mentioned using webhooks to notify ASLO when a new
>> activity
>> >     version has been released. Perhaps such a hook could be used to
>> notify you
>> >     of the need to review localization for the activity and another
>> hook to
>> >     notify ASLO to update the bundle to integrate the localization.
>> >
>> > I think this is the right approach.
>> >
>> > From the conversations so far and looking at the [2]ASLO 3 Proposal, we
>> are
>> > using webhooks to notify ASLO of any changes, whether it is adding a new
>> > activity, or updating an existing one. I have one question, how will an
>> > activity get approved prior to it's release on ASLO ?
>> > Suppose a developer wants to create a new activity and upload it to
>> > ASLO. Of course, prior to release, the activity needs to be
>> > verified/moderated. Will be there an intermediate step? Since
>> > developer needs to be member of sugar-activites organization to
>> > publish an activity there or will there be another repository
>> > containing names of verified repo, which build server will check on
>> > each webhook ?
>> > What I suggest is to use the Pull request reviews to moderate an
>> > activity and when an activity is signed off as okay but X number of
>> >  senior members then only it should be considered for ASLO.
>>
>> That would work, but it sounds difficult to communicate and implement;
>> there are not enough senior members.  ;-)
>>
>> We also can't trust GitHub to keep that UX stable.
>>
>> > My main query is, how we will accomplish moderation and publishing
>> > to ASLO using Github as a tool ? I might be wrong about the whole
>> > moderation thing but a healthy discussion will hopefully lead us in
>> > the right direction.
>>
>> What we have now is a moderation queue in a PHP application; perhaps
>> we don't need a moderation or approval at all.  That would simplify
>> the activity release process by one step.
>>
>> We already have patch review; much better moderation or approval than
>> we had before.
>>
>> Let's drop the moderation and approval requirement.  Leave it to the
>> image builders if they want to go further.  Speaking as an image
>> builder.
>>
>> --
>> James Cameron
>> http://quozl.netrek.org/
>>
>
>
>
> --
> Laura V.
> * I&D SomosAZUCAR.Org*
>
> “Solo la tecnología libre nos hará libres.”
> ~ Laura Victoria
>
> Happy Learning!
> #LearningByDoing
> #Projects4good
> #IDesignATSugarLabs
> #WeCanDoBetter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20170519/329e2589/attachment-0001.html>