[Sugar-devel] Sugar Digest 2013-12-25

[Walter Bender]

Happy holidays.

==Sugar Digest==

''Between the ages of five and nine, I was almost perpetually at war
with the education system... As soon as I learned from my mother that
there was a place called school that I must attend willy nilly—a place
where you were obliged to think about matters prescribed by a
'teacher,' not about matters decided by yourself—I was appalled.''
—Fred Hoyle

1. Another sweet year: Each year I am asked to write up a summary of
the Sugar Labs activity for the Software Freedom Conservancy annual
report. Here is a draft of this year's report.

;JS/HTML5: Last year, our major major technical effort was the
transition to GNOME Toolkit 3. This year, we have been focusing on
adding Javascript/HTML5 support to Sugar. Under the leadership of
Daniel Narvaez, Manuel Quiñones, and Lionel Laské, the developer team
has made Javascript/HTML5 a first-class development environment, i.e.,
you can write Sugar activities in Javascript and they will behave in a
manner equivalent to Python/Gtk3 activities, with Journal support,
Sugar toolbars, etc. At the same time, these activities can run in a
web browser and can readily be ported to platforms such as Android.
This has been a community effort with contributions coming from all
corners and has already attracted some new developers to the project.

;Web services: Another important technical development was the
addition of web services to Sugar. Born from a weekend of coding in
Raúl Gutiérrez Segalés's living room, Sugar now has a framework for
integrating with a wide variety of web services, enabling our users to
take advantage of file sharing and social network utilities directly
from within the Sugar Journal.

;Sugar activities: Our "app store" continues to grow, thanks in large
part to contributions from Sugar users who have made the transition to
Sugar developers. The trend of apps written by children who grew up
with Sugar is holding: still more than 10% of our apps were written by
children and at least 30% are maintained by children. Those numbers
may increase given a recent development: thanks to the efforts of
Marion Zepf, a Google Summer of Code intern, we can now export Python
code from Turtle Art, one of the block-based programming environments
in Sugar. From there, you are literally two mouse-clicks away from
turning your program into a Sugar activity, which can be shared with
friends or uploaded to the app store. Meanwhile, we are approaching
ten-million downloads from our app store.

;Sugar core: We landed a number of enhancements created by our users.
Some of my favorites from the past year are oriented towards end-user
customization. We designed Sugar with a sparse aesthetic not because
we wanted to promote Swiss design or because we were lacking access to
professional designers; rather we wanted to let our users "complete"
the look and feel to their own specifications. This is getting easier:
Daniel Francis implemented multiple home views; Agustin Zubiaga
Sanchez implemented background image support; Ignacio Rodríguez
implemented a tool for customizing icons.

;Internationalization push: Chris Leonard continues to recruit and
assist translation teams so that Sugar has better coverage in the
mother tongues and indigenous languages of our users. One highlight of
the past year is that Edgar Quispe completed the translation of Sugar
into Aymara, one of the major indigenous languages of Peru. We have
some funding from the Trip Advisor Foundation to expand our outreach
for internationalization and are currently making a push to recruit
more translators in Māori, Haitian Creole, Khmer, Gurani, and Quechua.
(A tip of the hat to Larry Denenberg, whom has been working on the
Hebrew translations and also made the connection between Trip Advisor
Foundation and Sugar Labs.) Chris is also leading an effort to help
upstream support for some of these languages, and we continue to host
translation efforts for many upstream projects.

;TA Days: Also through the generosity of the Trip Advisor Foundation,
we have been celebrating Turtle Art Days: so far in Paraguay, Uruguay,
Singapore, Malaysia, Costa Rica, and Peru. Thanks to Claudia Urrea and
the learning team who have made these events possible, helping us to
promote programming as core pedagogical construct.

;Sugar and robotics: From the Butiá project begun at FING in
Montevideo, we've seen huge growth in the interest in using Sugar (and
in particular, Turtle Art) as a medium for introducing children to
programming robotics. Andres Aguirre and Alan Aguiar have worked
closely with Sugar Labs to develop a comprehensive programming
environment and curriculum around robots. The latest "fork" is Junky,
a project lead by Martin Abente in Asuncion. Meanwhile efforts to
better support Sugar on platforms such as Raspberry Pi continue: one
of our goals is to make Sugar suitable and desirable as a platform for
the growing Maker movement.

;Sugar on a Stick: There have been almost 1,000,000 visits to the
Sugar on

Re: [Sugar-devel] About bug notation in commit headers

[Gonzalo Odiard]

If there are not objections, I will send a patch to sugar-docs


On Tue, Dec 24, 2013 at 6:01 PM, Daniel Narvaez  wrote:

> Sounds good to me.
>
>
> On 19 December 2013 13:36, Gonzalo Odiard  wrote:
>
>> In the past, we used to add in the first line of the commit message
>> the bug number, with the prefixes SL or OLPC, depending on if
>> the ticket was in bugs.sugarlabs.org or in dev.laptop.org.
>> The reference in the first line was useful to find the connection,
>> by example when you do git log --oneline
>>
>> Many moons ago, olpc team moved all the work related to sugar and
>> activities,
>> to sugarlabs bug tracker, then right now the prefix is not needed anymore.
>>
>> Now, we have magic rules to close a ticket if the "Fixes #number"
>> is found in the header.
>>
>>
>> https://github.com/sugarlabs/sugar-docs/blob/master/contributing.md#bugfixing
>>
>> The rule works in the first line too.
>>
>> Then I propose:
>>
>> * Continue using Fixes # without prefixes.
>> * Use it in the first line of the header.
>> * Modify documentation to request this.
>>
>>  What you think?
>>
>> Gonzalo
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>
>
> --
> Daniel Narvaez
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Gambiarra game

[Bernie Innocenti]

+1 from me as well.

For the record: I drafted the current policy a couple of years ago in
the attempt to give activity developers a clearly documented process
that they can just follow without getting stuck into a long policy
discussion.

As Daniel noted, the current process seems a bit too laborious and I
would support shortening it in the future. To me, "the Activity Team
coordinator decides on a case-by-case basis" would work too. The
important point is documenting the process in advance so everyone knows
how to handle future cases.


On 12/24/2013 04:22 PM, Daniel Narvaez wrote:
> +1
> 
> On Tuesday, 24 December 2013, Walter Bender wrote:
> 
> It is current and we should be following it, IMHO.
> 
> -walter
> 
> On Tue, Dec 24, 2013 at 3:57 PM, Daniel Narvaez  > wrote:
> > (Assuming the policy is not obsolete or something, I think we
> should move it
> > to developer.sugarlabs.org ).
> >
> >
> > On 24 December 2013 21:51, Daniel Narvaez  > wrote:
> >>
> >> By the way, we seem to have a non responsive maintainer policy
> already.
> >>
> >>
> >>
> 
> http://wiki.sugarlabs.org/go/Activity_Team/Policy_for_nonresponsive_maintainers
> >>
> >> Any reason we are not following it?
> >>
> >>
> >> On 24 December 2013 21:49, Daniel Narvaez  > wrote:
> >>>
> >>> On 24 December 2013 15:10, Aleksey Lim  > wrote:
> 
>  On Tue, Dec 24, 2013 at 08:49:02AM -0500, Walter Bender wrote:
>  > IMHO, the git rep is less the issue than the ownership on
> ASLO. git is
>  > set up for forks, ASLO less obvious. I can give Alan joint
> ownership
>  > on ASLO. (The versions available from Luiz will still be
> available
>  > even after Alan uploads new ones.)
> 
>  I don't see how ASLO is critically different in comparison with
> git.sl.o
>  in this case (passing ownership).
> >>>
> >>>
> >>> ASLO is more similar to a distribution than to gitorious
> repositories and
> >>> distributions usually have non-responsive maintainer policies
> >>>
> >>>
> >>>
> 
> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
> >>>
> >>>
> >>>
> 
> http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa
> >>>
> 
>  At the end, the important thing is that
>  both versions should be available for users (the original
> version, and
>  the one which was improved by new developers). It is hardly
> possible to
>  have only one download entity [on ASLO].
> >>>
> >>>
> >>> If we have to choose, I think it's more important to make an
> improved
> >>> activity available then old versions provided by the original
> maintainer.
> >>>
> 
>  In any case, that might be a topic for SN (as an ASLO's superset)
>  to handle this kind of issues in the future.
> >>>
> >>>
> >>>  We can reevaluate when SN takes over, but given the current
> >>> infrastructure I think giving Alan joint ownership is the most
> pragmatic
> >>> approach.
> >>
> >>
> >>
> >>
> >> --
> >> Daniel Narvaez
> >
> >
> >
> >
> > --
> > Daniel Narvaez
> 
> 
> 
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> 
> 
> 
> -- 
> Daniel Narvaez
> 


-- 
 _ // Bernie Innocenti
 \X/  http://codewiz.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel