Re: [Sugar-devel] New ASLO Project Definition

2017-05-22 Thread James Cameron 
https://wiki.sugarlabs.org/go/Features/Feature_Template

On the one hand it is a useful template to guide a consensus approach,
most of us are familar with it, and it ties into the release process.

On the other hand,

- the feature process is tied to the Wiki, and as most people here
  aren't using the Wiki it may be exclusionary to demand it, just as
  it is exclusionary to demand use of Google Docs,

- the feature process has been used and tuned more for Sugar than for
  server infrastructure, and;

- the process is tied to a regular Sugar platform release schedule,
  which we have since lost.

It may be more effective to document the design in parts, posting each
part to the sugar-devel@ mailing list as it becomes available.

Holding back until a design is complete, and therefore lengthy, will
trigger a TL;DR response.

On Sat, May 20, 2017 at 09:55:59AM +0800, Tony Anderson wrote:
> Is a wiki features page the right way to get the design documented for this
> project?
> 
> Tony
> 
> On 05/20/2017 05:54 AM, Walter Bender wrote:
> 
> One of the pre-summer tasks is to answer that question. 
> 
> On May 19, 2017 5:51 PM, "James Cameron" <[1]qu...@laptop.org> wrote:
> 
> Samuel & Jatin,
> 
> Rather than make a new Django app to replace a PHP app, please
> consider the previous New ASLO written by Sam Parkinson with help from
> many of us here.
> 
> [2]https://github.com/samdroid-apps/aslo
> 
> This work started around 16th April 2014, and the last commit was on
> 18th July 2015.
> 
> It is written in Python, uses Flask, Docker, git, and has a workflow
> that is very close to what Samuel has defined.
> 
> Instead of a separate GitHub organisation, Sam designed a registry
> repository;
> 
> [3]https://github.com/samdroid-apps/sugar-activities
> 
> This uses JSON metadata derived in part from the .info files.
> 
> An aslo-bot was responsible for detecting releases in activity
> repositories and adjusting the registry.
> 
> The New ASLO is already integrated with the Social Help discourse
> forum.
> 
> Chris has reminded us, the New ASLO already has translations;
> [4]https://translate.sugarlabs.org/projects/NewAslo/
> 
> So please explain why Sam's work cannot be used?
> 
> --
> James Cameron
> [5]http://quozl.netrek.org/
> ___
> Sugar-devel mailing list
> [6]Sugar-devel@lists.sugarlabs.org
> [7]http://lists.sugarlabs.org/listinfo/sugar-devel
> 
>
> ___
> Sugar-devel mailing list
> [8]Sugar-devel@lists.sugarlabs.org
> [9]http://lists.sugarlabs.org/listinfo/sugar-devel
> 
> References:
> 
> [1] mailto:qu...@laptop.org
> [2] https://github.com/samdroid-apps/aslo
> [3] https://github.com/samdroid-apps/sugar-activities
> [4] https://translate.sugarlabs.org/projects/NewAslo/
> [5] http://quozl.netrek.org/
> [6] mailto:Sugar-devel@lists.sugarlabs.org
> [7] http://lists.sugarlabs.org/listinfo/sugar-devel
> [8] mailto:Sugar-devel@lists.sugarlabs.org
> [9] http://lists.sugarlabs.org/listinfo/sugar-devel

> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel


-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New ASLO Project Definition

2017-05-19 Thread Tony Anderson 
Is a wiki features page the right way to get the design documented for 
this project?


Tony


On 05/20/2017 05:54 AM, Walter Bender wrote:

One of the pre-summer tasks is to answer that question.


On May 19, 2017 5:51 PM, "James Cameron" > wrote:


Samuel & Jatin,

Rather than make a new Django app to replace a PHP app, please
consider the previous New ASLO written by Sam Parkinson with help from
many of us here.

https://github.com/samdroid-apps/aslo


This work started around 16th April 2014, and the last commit was on
18th July 2015.

It is written in Python, uses Flask, Docker, git, and has a workflow
that is very close to what Samuel has defined.

Instead of a separate GitHub organisation, Sam designed a registry
repository;

https://github.com/samdroid-apps/sugar-activities


This uses JSON metadata derived in part from the .info files.

An aslo-bot was responsible for detecting releases in activity
repositories and adjusting the registry.

The New ASLO is already integrated with the Social Help discourse
forum.

Chris has reminded us, the New ASLO already has translations;
https://translate.sugarlabs.org/projects/NewAslo/


So please explain why Sam's work cannot be used?

--
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org

http://lists.sugarlabs.org/listinfo/sugar-devel




___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New ASLO Project Definition

2017-05-19 Thread James Cameron 
On Fri, May 19, 2017 at 05:57:18PM -0400, Samuel Cantero wrote:
> I thought the community had the answer about why ASLOv2 failed!

What was the answer?

-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New ASLO Project Definition

2017-05-19 Thread James Cameron 
On Fri, May 19, 2017 at 06:13:44PM +0800, Tony Anderson wrote:
> Thanks for the list of Fructose activities, I have been trying to
> find a definitive list since the issue was raised.

I'm surprised.  Just ask next time?  You asked on a Debian mailing
list, but it was off-topic for that list, and your later posts seemed
to indicate you now understood.

Definitive list is;

https://wiki.sugarlabs.org/go/Development_Team/Release/Modules#Fructose
activities are added or removed from this list over time, the
list change history is in the "View history" link, and the departure
of activity maintainers has not been noted,

Another list is;

http://download.sugarlabs.org/sources/sucrose/fructose/
new activities are added to this list, old activities remain, and the
URLs are referenced by the Fedora and Debian infrastructure that
detects new releases for packaging.

Fructose is of most use by the release manager of Sugar; Daniel N,
then Martin, then Sam, now Ignacio.  It is the list of activities that
the release manager must test with before releasing Sugar.

https://wiki.sugarlabs.org/go/Development_Team#Release_manager
https://wiki.sugarlabs.org/go/Development_Team/Release

-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New ASLO Project Definition

2017-05-19 Thread Samuel Cantero 
I thought the community had the answer about why ASLOv2 failed! Personally,
I would love to review Sam's ASLO.

Best,

Sam C.


On Fri, May 19, 2017 at 5:54 PM, Walter Bender 
wrote:

> One of the pre-summer tasks is to answer that question.
>
>
> On May 19, 2017 5:51 PM, "James Cameron"  wrote:
>
>> Samuel & Jatin,
>>
>> Rather than make a new Django app to replace a PHP app, please
>> consider the previous New ASLO written by Sam Parkinson with help from
>> many of us here.
>>
>> https://github.com/samdroid-apps/aslo
>>
>> This work started around 16th April 2014, and the last commit was on
>> 18th July 2015.
>>
>> It is written in Python, uses Flask, Docker, git, and has a workflow
>> that is very close to what Samuel has defined.
>>
>> Instead of a separate GitHub organisation, Sam designed a registry
>> repository;
>>
>> https://github.com/samdroid-apps/sugar-activities
>>
>> This uses JSON metadata derived in part from the .info files.
>>
>> An aslo-bot was responsible for detecting releases in activity
>> repositories and adjusting the registry.
>>
>> The New ASLO is already integrated with the Social Help discourse
>> forum.
>>
>> Chris has reminded us, the New ASLO already has translations;
>> https://translate.sugarlabs.org/projects/NewAslo/
>>
>> So please explain why Sam's work cannot be used?
>>
>> --
>> James Cameron
>> http://quozl.netrek.org/
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New ASLO Project Definition

2017-05-19 Thread Walter Bender 
One of the pre-summer tasks is to answer that question.


On May 19, 2017 5:51 PM, "James Cameron"  wrote:

> Samuel & Jatin,
>
> Rather than make a new Django app to replace a PHP app, please
> consider the previous New ASLO written by Sam Parkinson with help from
> many of us here.
>
> https://github.com/samdroid-apps/aslo
>
> This work started around 16th April 2014, and the last commit was on
> 18th July 2015.
>
> It is written in Python, uses Flask, Docker, git, and has a workflow
> that is very close to what Samuel has defined.
>
> Instead of a separate GitHub organisation, Sam designed a registry
> repository;
>
> https://github.com/samdroid-apps/sugar-activities
>
> This uses JSON metadata derived in part from the .info files.
>
> An aslo-bot was responsible for detecting releases in activity
> repositories and adjusting the registry.
>
> The New ASLO is already integrated with the Social Help discourse
> forum.
>
> Chris has reminded us, the New ASLO already has translations;
> https://translate.sugarlabs.org/projects/NewAslo/
>
> So please explain why Sam's work cannot be used?
>
> --
> James Cameron
> http://quozl.netrek.org/
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New ASLO Project Definition

2017-05-19 Thread James Cameron 
Samuel & Jatin,

Rather than make a new Django app to replace a PHP app, please
consider the previous New ASLO written by Sam Parkinson with help from
many of us here.

https://github.com/samdroid-apps/aslo

This work started around 16th April 2014, and the last commit was on
18th July 2015.

It is written in Python, uses Flask, Docker, git, and has a workflow
that is very close to what Samuel has defined.

Instead of a separate GitHub organisation, Sam designed a registry
repository;

https://github.com/samdroid-apps/sugar-activities

This uses JSON metadata derived in part from the .info files.

An aslo-bot was responsible for detecting releases in activity
repositories and adjusting the registry.

The New ASLO is already integrated with the Social Help discourse
forum.

Chris has reminded us, the New ASLO already has translations;
https://translate.sugarlabs.org/projects/NewAslo/

So please explain why Sam's work cannot be used?

-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New ASLO Project Definition

2017-05-19 Thread Tony Anderson 


Thanks very much for this. I am optimistic that our path is converging.

* The "python setup.py genpot" step implemented in BundleBuilder does 
extract the summary and description for localisation.


The best problem is one that is already solved.

* The root problem is the loss of activity maintainers.

Couldn't agree more. Hopefully by next-year's GSOC, we can 
have more focus on the roles of activity maintainer and activity developer.



Thanks for the list of Fructose activities, I have been trying to find a 
definitive list since the issue was raised.


I agree with your handling of the distribution. Walter has also made the 
point in the GSOC meetings to use sugar_dev.


Your comments about 'Why a new ASLO' have cleared up a lot for me. I see 
ASLO as a place where Sugar users go to get new activities to install on 
their laptops. As an image builder, you are properly focused on the core 
set of activities you need to include.


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.


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


Won't take the bet. It won't make things worse, but it could be a waste 
of time.  However, I am very optimistic because of the level of 
attention this project has already gained. This is the best insurance 
for a useful design and postive outcome.


As I see the activity development procedure:

Just as for Sugar core, a change to an activity would be requested by 
the developer and then tested by a maintainer. If acceptable, a new 
version would be committed as a branch with a message such as 'v23'. At 
this point the maintainer makes the xo bundle and copies it to the 
download.sugarlabs.org/activities

directory. ASLO would show the new bundle as the 'latest'.

A new activity could be developed in a personal github repository. The 
developer, when ready, can request it to be made a repository on the 
Sugar activities github. This would be done by an activity maintainer 
with 'owner' permissions.


Tony

On 05/19/2017 03:04 PM, James Cameron wrote:

Composite reply to several posts, see text in quoted context below.

In summary;

- the translation of summary and description is already handled by
   sugar3.activity.bundlebuilder module,

- a root problem is loss of activity maintainers, and this effort
   won't fix that, so it will be wasted effort; we still won't have
   updated activities after it is finished,

- myself and other image builders have worked around the problem,

- it is the Fructose collection that is most critical; the set of
   demonstration activities that are included in every image,

- the regular Fructose activity developers in the past year were
   Walter, Sebastian, Alan, Sam Parkinson, Gonzalo, and myself;
   although both Sam and Gonzalo have signalled their disengagement,

- while we have retained new developers from GSoC and GCI, they have
   concentrated on the core rather than activities,

- automatic bundle creation will be vulnerable to subversion, and is
   not suitable for all activities.

On Thu, May 18, 2017 at 05:14:34PM -0400, Samuel Cantero wrote:

I just realized that proposal wasn't send to sugar-devel list. It
was removed from the thread at some point. So I just forward the
link again. Sorry for people subscribed to multiple lists.

I've trimmed addressees.  No need to copy those extra people, they are
already on sugar-devel@, and no need to copy iaep@ because this is a
development discussion.

I've changed CC of Aleksey because their @sugarlabs.org address hasn't
been used for years, and I don't know if it works.


https://goo.gl/VEIzCr

Copied and pasted below.

Please, in future, attach it or include it in mail, so that it can be
found in mailing list archives.  Links to external documents
eventually fail, and people may change them after the mail is sent.


Outline for ASLO Version 3

Why a new ASLO?

* Developers should maintain up-to-date information of their
activities in two places: the GitHub repository and ASLO. This has
led to a very out-of-date ASLO. We can overcome this, giving
developers the chance to only update the GitHub repository and
forget about changes in ASLO.

No.  I disagree with the conclusion.  The reasons ASLO is out of date
are;

- there have been no new activity releases, because activity
   maintainers have left, and no new maintainers joined,

- those of us building images have bypassed activity maintainers by
   making point release bundles or applying patch collections.

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.

As a consequence of

Re: [Sugar-devel] New ASLO Project Definition

2017-05-19 Thread James Cameron 
Composite reply to several posts, see text in quoted context below.

In summary;

- the translation of summary and description is already handled by
  sugar3.activity.bundlebuilder module,

- a root problem is loss of activity maintainers, and this effort
  won't fix that, so it will be wasted effort; we still won't have
  updated activities after it is finished,

- myself and other image builders have worked around the problem,

- it is the Fructose collection that is most critical; the set of
  demonstration activities that are included in every image,

- the regular Fructose activity developers in the past year were
  Walter, Sebastian, Alan, Sam Parkinson, Gonzalo, and myself;
  although both Sam and Gonzalo have signalled their disengagement,

- while we have retained new developers from GSoC and GCI, they have
  concentrated on the core rather than activities,

- automatic bundle creation will be vulnerable to subversion, and is
  not suitable for all activities.

On Thu, May 18, 2017 at 05:14:34PM -0400, Samuel Cantero wrote:
> I just realized that proposal wasn't send to sugar-devel list. It
> was removed from the thread at some point. So I just forward the
> link again. Sorry for people subscribed to multiple lists.

I've trimmed addressees.  No need to copy those extra people, they are
already on sugar-devel@, and no need to copy iaep@ because this is a
development discussion.

I've changed CC of Aleksey because their @sugarlabs.org address hasn't
been used for years, and I don't know if it works.

> https://goo.gl/VEIzCr

Copied and pasted below.

Please, in future, attach it or include it in mail, so that it can be
found in mailing list archives.  Links to external documents
eventually fail, and people may change them after the mail is sent.

> Outline for ASLO Version 3
> 
> Why a new ASLO?
> 
> * Developers should maintain up-to-date information of their
> activities in two places: the GitHub repository and ASLO. This has
> led to a very out-of-date ASLO. We can overcome this, giving
> developers the chance to only update the GitHub repository and
> forget about changes in ASLO.

No.  I disagree with the conclusion.  The reasons ASLO is out of date
are;

- there have been no new activity releases, because activity
  maintainers have left, and no new maintainers joined,

- those of us building images have bypassed activity maintainers by
  making point release bundles or applying patch collections.

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.

As a consequence of losing activity maintainers, moving to one place
for updates won't fix the problems.

What Sugar Labs has not done is replace the activity maintainers that
have left.  The underlying problem is sustainability of an open
source community.  Nagia Eghbal of GitHub has recommended several
actions in her book "Roads and Bridges: The Unseen Labor Behind Our
Digital Infrastructure"

https://fordfoundcontentthemes.blob.core.windows.net/media/2976/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf

"Some projects have experimented with making it easier to contribute."

Another project's policy "emphasizes growing the number of
contributors and empowering them to make their own decisions, instead
of treating maintainers as the final approving authority."

In a recently abandoned discussion of Sugar Labs goals;
https://wiki.sugarlabs.org/go/2017_Goals

For the goal "Develop, distribute, and maintain a variety of Sugarizer
Apps and installations for as many devices as possible", is an
objective "Actively recruit and maintain developers for Sugarizer",
and "Make the platform easier for developers to contribute" action
item.  Lionel gets it.  Yet nothing for Sugar desktop activity
maintainers.  And the Sugarizer activities are not being developed to
be portable back to Sugar desktop.

The role of an activity maintainer is to accept changes from others,
test the activity, iterate with fixes, update version, tag a release,
make a bundle, upload to ASLO, upload to download.sugarlabs.org, and
field any questions that arise.

Developers in the past year for the Fructose "set of demonstration
activities", are;

- Chat; Walter, Leonard, and myself,
- Browse; Leonard, Sebastian, and myself,
- Read; Walter, Leonard, and myself,
- Calculate; Walter, Leonard, myself,
- Log; Walter, and Leonard,
- Write; Walter, Leonard, and Gonzalo,
- Terminal; Leonard, and Sam Parkinson,
- Pippy; Leonard, Walter, Sebastian, Ignacio, and myself,
- Etoys; none,
- ImageViewer; Leonard, Walter, and myself,
- Jukebox; Leonard, Walter, and myself,
- Turtleart; Walter, Leonard, Alan and Sebastian,

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

Re: [Sugar-devel] New ASLO Project Definition

2017-05-18 Thread Tony Anderson 

Hi Chris

Currently there are two text fields per activity in ASLO: Summary and 
Description.
This gets a bit more complicated since these text fields edited by the 
developer in github.


Perhaps this might work. Have a po directory in the activities/ 
directory of the bundle. When the activity page is selected Django can 
select the summary string from the appropriate po and send it to the 
html template. This method would work for both summary and description. 
With the pootle default to display the POT string, no harm can be done.


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.


Tony

On 05/19/2017 10:08 AM, Chris Leonard wrote:

On Thu, May 18, 2017 at 9:57 PM, Tony Anderson  wrote:

On 05/19/2017 09:24 AM, Chris Leonard wrote:
The more difficult question is how to localize the summary and description
of the individual activities. At present, it appears we don't attempt to
localize this information.

The first thought that pops into my mind is the very brief Activity
description that is in the activity.info file and is frequently, but
not always captured in the PO file for localization.  With that as
background, making changes to activity,info format to include a richer
description seems feasible as does doing a better job of tooling the
i18n so that these activity.info fields are more consistently captured
in the PO files.  Having ASLO parse the activity.info file of the
hosted packages relevant PO file seems a reasonable approach that
would mean that ASLO doesn't have to have separately maintained
knowledge of the Activities being hosted, it justs picks it up from
the upload of the package itself.  . Just a thought.

cjl
.



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New ASLO Project Definition

2017-05-18 Thread Chris Leonard 
On Thu, May 18, 2017 at 10:36 PM, Tony Anderson  wrote:
> Hi, Jatin
>
> I think you are familiar with Pootle. The trick with Django is that the
> display of strings is indirect.
>
> First, the locale is set client-side so ASLO needs to determine the
> applicable locale - presumably from a message header. This information is in
> the request paramater.
>
> Second, views.py needs to retrieve the localized string and send it to the
> template. The template then needs to display text by {{ text }}.
>
> Probably it would be easier to use the po files (the mo files would involve
> a double conversion). A directory of these files
> would need to be available to Django - easy to do either by putting it under
> the static root or in the application directory (I often use fixtures).
>

I am by no means a Django expert, but I would note that Pootle itself
uses Django and that Pootle localization is hosted in Pootle, which
suggests to me that any such challenges are not insurmountable.  The
Pootle guys are really nice folks and very willing to share their
insight into i18n/L10n in general, in my experience.  They hang out on
a Gitter site https://gitter.im/translate/pootle and I'd be happy to
make introductions to anyone interested.

cjl
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New ASLO Project Definition

2017-05-18 Thread Tony Anderson 

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 agree with your proposal to install the activity repositories in 
https://github.com/sugar-activities/. Combining 600+ repositories in 
with the Sugar core repositories seems unmanageable. Someone would need 
to create this community on github. This needs to be decided quickly so 
the repostiroies are in place to support ASLO. We have to get past 
Walter saying this is what we are doing and James Cameron saying no 
decision has been made.


Some more detailed comments on the proposal:

*Actors and use cases*

I think there is a fourth, very important actor, the deployer. The 
deployer needs to configure a laptop installation but does not have the 
technical skills to build an image. A practical solution is to flash a 
prebuilt image (e.g. 13.2.8) and then update the activity configuration 
as needed. The best help we could provide for the developer is a network 
install capability from the institution's lan.


Since James Cameron (and possibly Jonas Smedegaard) are the only image 
builders I know of, it seems hard to justify automation. Perhaps the 
scope of the 'update url' should be shifted to providing a build system 
that creates a Sugar image for various target systems.


*Workflows*

1. The other requirement is for an 'owner' to create the repository. 
This is analogous to the current procedure in ASLO.
2. I think the event should be 'new version released'. I am a git newbie 
(actually an old dog having trouble with new tricks) but I think git 
practice is to signal a release by creating a branch. This creation 
could generate the signal.
3. On the ASLO side, I think the information needs to be in 
activity.info. If this is done ASLO side, then the published bundle will 
not match the repository. If all of the information is in activity.info 
(or other file in the activity/ directory), the developer would have 
complete control over it.
3. I assume tar files are used in xol bundles. So far these are not 
published on ASLO. I think xol bundles should be handled independently 
of ASLO.


Tony


On 05/19/2017 05:14 AM, Samuel Cantero wrote:
I just realized that proposal wasn't send to sugar-devel list. It was 
removed from the thread at some point. So I just forward the link 
again. Sorry for people subscribed to multiple lists.


Best,

Sam C.

On Wed, May 17, 2017 at 4:06 PM, James Cameron > wrote:


Yes, please attach any files that developers should see.

The sugar-devel@ mailing list has a message size limit of 1024K.

Messages above the limit are held for approval by Sebastian and I.

My previous offer still stands; if people truly have no time to edit a
Wiki, set up public web hosting, or upload to github, send it as mail
to the list and I'll approve it.

http://lists.sugarlabs.org/archive/sugar-devel/2017-May/054193.html 


On the other hand, there have been Wiki edits in the last few
hours thanks to Walter;


http://wiki.sugarlabs.org/index.php?title=Summer_of_Code=2570=100299=100290



Progress.  Yay.

--
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org

http://lists.sugarlabs.org/listinfo/sugar-devel





___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New ASLO Project Definition

2017-05-18 Thread Samuel Cantero 
I just realized that proposal wasn't send to sugar-devel list. It was
removed from the thread at some point. So I just forward the link again.
Sorry for people subscribed to multiple lists.

https://goo.gl/VEIzCr

Best,

Sam C.

On Wed, May 17, 2017 at 4:06 PM, James Cameron  wrote:

> Yes, please attach any files that developers should see.
>
> The sugar-devel@ mailing list has a message size limit of 1024K.
>
> Messages above the limit are held for approval by Sebastian and I.
>
> My previous offer still stands; if people truly have no time to edit a
> Wiki, set up public web hosting, or upload to github, send it as mail
> to the list and I'll approve it.
>
> http://lists.sugarlabs.org/archive/sugar-devel/2017-May/054193.html
>
> On the other hand, there have been Wiki edits in the last few
> hours thanks to Walter;
>
> http://wiki.sugarlabs.org/index.php?title=Summer_of_
> Code=2570=100299=100290
>
> Progress.  Yay.
>
> --
> James Cameron
> http://quozl.netrek.org/
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New ASLO Project Definition

2017-05-17 Thread James Cameron 
Yes, please attach any files that developers should see.

The sugar-devel@ mailing list has a message size limit of 1024K.

Messages above the limit are held for approval by Sebastian and I.

My previous offer still stands; if people truly have no time to edit a
Wiki, set up public web hosting, or upload to github, send it as mail
to the list and I'll approve it.

http://lists.sugarlabs.org/archive/sugar-devel/2017-May/054193.html

On the other hand, there have been Wiki edits in the last few
hours thanks to Walter;

http://wiki.sugarlabs.org/index.php?title=Summer_of_Code=2570=100299=100290

Progress.  Yay.

-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel