[Sugar-devel] [ASLO] Release Image Viewer-22

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4032

Sugar Platform:
0.86 - 0.98

Download Now:
http://activities.sugarlabs.org/downloads/file/28533/image_viewer-22.xo

Release notes:
* Fullscreen is useless #3704
* Update translations


Sugar Labs Activities
http://activities.sugarlabs.org

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

[Sugar-devel] Fwd: Proposal on how to speed up patch reviews

[Daniel Narvaez]

Forgot to reply all...


-- Forwarded message --
From: Daniel Narvaez 
Date: 25 March 2013 21:12
Subject: Re: [Sugar-devel] Proposal on how to speed up patch reviews
To: Simon Schampijer 


On 25 March 2013 12:37, Simon Schampijer  wrote:
> To improve that situation, I think we have to put some lights on all those
> roles and I think often the situation of the maintainer is not understood
> well enough. I can at least say that we had this discussions for the last
> years in Sugar, with different maintainers and I have seen it happening in
> many other projects as well. It is a known issue, and it is not an easy one,
> never less I think we can improve.

In my experience Sugar has been much worst than both GNOME and mozilla
though. I know it's not easy but we should keep trying.

(I hope it's absolutely clear that I'm not blaming anyone for the
situation, just pointing out the importance of fixing it or at least
trying to)

> [bugfix] A bugfix is the simplest case. The submitter is interested in
> solving the specific issue he is working on. It is not hard to find a
> reviewer or tester. Either someone from the community that has been annoyed
> by the same issue or the maintainer himself because he is interested in
> seeing the issue solved, his interest is a working code base in the end.
> Here it is easy as well for a maintainer to trust another reviewer and
> acknowledge based on his positive review.
>
> In my experience those patches are not laying around for long if there is
> not a technical blocker in the patch itself. Evaluation is relatively easy
> here.

I had at least one obvious bug fix patch unreviewed for months. Maybe
I was unlucky. Anyway I agree this is the easiest of the cases and
where things work best.

> [feature] When it gets to Features things get more tricky. For a Feature
> first of all the high level goals are important: what need does the Feature
> address, is it wanted by the community, is the technical approach taken a
> good one, basically the maintainer has to decide if it is worth taking on
> maintainership of this feature or not. In the end it might be him who has to
> deal with arising bug fixes and who is blamed if the software is not a solid
> product.

While I agree with you in general, I think maybe we are exagerating a
bit the responsibility of the maintainers a bit. I tend to think it's
the whole community which will get the blame if things goes wrong...
Maintainers have of course a very important role, but they should not
feel like they alone into this.

> That might explain a general bigger resistance to features by maintainers.
> How can we help each other to make this a better process?

I think narrowing the focus is the best we can do, but I'll elaborate
more about that while answering Gonzalo email.

> [feature/UI] All what have been said above applies to the feature that adds
> UI as well. I have separated that item because it adds another complexity.
> We have the UI process for this (as written in the feature policy [1]).
> Basically it adds more care taking of all the roles involved.

Even if we go with my propiosal, I think maintainers should keep a
strong supervision role on features, UI or not. I'd say it's
responsibility of the reviewer to make sure the maintainer is happy in
this regard... we should add it to our review checklist (well we don't
have one yet afaik, but we should).

>> Online services patches, unreviewed  for more than one month
>> http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041808.html
>> Unreviewed for more than one month
>
>
> This one is part of the [feature] category. It can be mostly explained with
> the maintainers having their heads still in bug fixing for 0.98.
>
> Here applies as well what I said with high level descriptions of features
> and the feature process [2].

In an ideal world, a reviewer which is not busy with 0.98 should have
given a first pass to the patches and at the same time started a
discussion, involving the maintainer, about the oppurtunity of adding
such a feature etc.

>> * Let's separate the maintainer from the reviewer roles. Maintainers
>> should be very expert because ultimately the future of the project is
>> in their hands. Those kind of people are very rare. Though I think
>> there are many more people that could do reviews on areas of the code
>> they feel comfortable with.
>
>
> That sounds good to me. We actually are doing this more or less already. We
> can maybe make this more explicit and foster that principle. Especially for
> bug fixes I do not see a reason why I should not merge a patch that has
> r+/t+ from a trusted person if there is not an obvious issue.

There a couple of important differences compared to what we are doing:

* The reviewers are explicitly entrusted by the maintainers. So they
know if they review the patches will most likely go in. It's often not
very motivating to do reviews without being able to approve.
* The reviewers takes care of mer

Re: [Sugar-devel] Proposal on how to speed up patch reviews

[Daniel Narvaez]

On 25 March 2013 13:27, Gonzalo Odiard  wrote:
> While I agree in theory with all this,
> we can improve our actual situation if we look at our resources,
> time and people.
>
> * Time: we don't have a schedule, then feature discussion can't start.
> We can improve if we have a clear path and start to define what features
> will be included in the next cycle. I am sure different players
> right now have different ideas of what the next cycle can/should be,
> we need a agreement and try to push together.

Absolutely. I think finding consensus on a focus for the next release
is the top priority now. It's a discussion we should start, possibly
involving IAEP in it.

> * People: We don't have enough people really,
> and this situation can be temporally more difficult if some maintainer
> have by example  a baby :) (to not use the classic "Linus gets hit by a
> bus")
> As a project, we need take care of the people working with us,
> see at the personal situations, and the maintainers should
> open the door to more people to be involved if possible.
> For a long time, we had only Simon and Sascha doing sugar maintainership,
> and was not enough, now we have Simon and Manuq,
> and there are too much work to do. I think we should continue
> work on trying to get somebody else involved as maintainer.

The main goal of my proposal is exactly to open door to more people. I
think it's hard to find maintainers both because of the time
commitment and the experience required. We should keep looking but I
suspect we won't find them overnight. It's much easier to find
reviewers, I actually can think of several people in the community
that could cover that role very well already.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Features: Background image in Home View

[Walter Bender]

On Mon, Mar 25, 2013 at 12:41 PM, Manuel Quiñones  wrote:
> Counter-proposal:  add tiled backgrounds
>
> Mockup: http://dev.laptop.org/~manuq/bg-mockup.png
>
> - let the user select a shape (star, football, animal footsteps, etc)
> - the color of the shapes is selected by Sugar as the opposite to the
> XO colors and very light, almost white.  (Knowledge on Munsell colors
> is required to develop it)

I am pleased to see the reference to Munsell. (I used Munsell in part
to help with the design of the original set of XO colors and use it in
the Color Deducto activity). But I think if we were to go this route,
we won't need to burden the end user with needing to know about
Munsell; we can add a hue/value/chroma family for each XO color from
which we could improvise as part of xocolor.py. It'd be a nice
addition independent of this particular feature proposal.

-walter
>
> Future:
>
> - add a Shapes activity to design the shapes.
>
> What do you think?  Of course, we'll need developer hands for this.
>
> 2013/3/25 Manuel Quiñones :
>> Testing the latest patch..
>>
>> 2013/3/25 Gonzalo Odiard :
>>> Good catch.
>>>
>>> Replaced by the more pythonic:
>>>
>>> def _update_background_image(self, *args):
>>> self._background_pixbuf = None
>>> if BACKGROUND_IMAGE_PATH and os.path.exists(BACKGROUND_IMAGE_PATH):
>>> try:
>>>
>>> Gonzalo
>>
>> My first impression is that this feature can potentially hurt the
>> clean design of Sugar at some points:
>>
>> - the icons color semantic
>> - high contrast, accesibility
>>
>> I would like to know more about why is this a long requested feature,
>> who requests for it.  I suspect the requirement could come from people
>> who is used to conventional PCs, not from kids whos first interaction
>> with a computer is the XO.
>>
>> From the wiki page, I can't distinguish the good background examples
>> from the bad ones.  All look preety obstrusive to me.  In fact I can't
>> think how a good background could be.  Its colors should be far from
>> the grey outline, and far from the user colors too.  And the main
>> problem is that the user colors are different for each user, so a
>> background that works for a user could not work for the others.  In
>> case including this, a good testing contest could be: given a
>> background, provide the XO colors that make it fail.
>>
>> In case we have concensus including this, I have noticed that:
>>
>> - Adding it only in the home view kills the ilussion of having three
>> zoom views.  The background should be displayed in all three, I think.
>>
>> - I see the home view is not correctly aligned in the vertical axis.
>>
>> - Why it needs a restart?
>>
>> Cheers,
>>
>> --
>> .. manuq ..
>
>
>
> --
> .. manuq ..
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



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

Re: [Sugar-devel] Features: Background image in Home View

[Walter Bender]

On Mon, Mar 25, 2013 at 1:41 PM, Manuel Quiñones  wrote:
> 2013/3/25 Martin Langhoff :
>> On Mon, Mar 25, 2013 at 11:48 AM, Manuel Quiñones  wrote:
>>> My first impression is that this feature can potentially hurt the
>>> clean design of Sugar at some points:
>>>
>>> - the icons color semantic
>>> - high contrast, accesibility
>>
>> Agreed. IMHO it can be improved by applying a "washout" -- mix the
>> image with a white image at 50% alpha.
>
> Great, a washout is a simple and effective solution to my concerns.
> We can play with the percentage of white to get the best value.  I
> feel 60-70% could be better.
>
>>> I would like to know more about why is this a long requested feature,
>>
>> Identity is a strong human urge. Kids put stickers on them, adults buy
>> cars of different colors :-)
>
> You are right, and I have to say I love the art intervention kids do
> with stickers.  I was wondering if the home background was the right
> place.  Sounds like a valid reason.

I first proposed this feature after observing a school where the kids
were constantly switching back and forth between Sugar and GNOME. When
I asked why, they said it was so they could load a background image.
It was important to their sense of identity. It seemed that we should
offer this feature directly in Sugar.

This was further reinforced by the request by the president of
Amazonas to load a background image on their machines. We ended up
with a modified boot image as a compromise at the time, but it would
have been much preferred by the "customer" to have it on the home
screen.

Finally, while I agree that a background image can make a mess of any
desktop, including Sugar, it is also possible to design a background
that enhances the look. I defer to the imagination of our users in
that respect.

Regarding fading or mixing with white, I think it is dependent on the
image. Maybe let that be a degree of freedom with a reasonable
default?

>
>>> - Adding it only in the home view kills the ilussion of having three
>>> zoom views.  The background should be displayed in all three, I think.

Not 100% convinced, since the layout for the icons is different in
each view. I could imagine zooming out on the background image in some
interesting way as the view changes. Or just let the user choose
separate backgrounds for each view?

>>
>> +1
>
> Ideally the background could do a subtle zoom to better enhace the
> illussion.  Would require hardware acceleration though.  Could be left
> for future enhacement.
>
>>
>>> - Why it needs a restart?
>>
>> +1
>>
>>
>>
>>
>> m
>> --
>>  martin.langh...@gmail.com
>>  -  ask interesting questions
>>  - don't get distracted with shiny stuff  - working code first
>>  ~ http://docs.moodle.org/24/en/User:Martin_Langhoff
>
>
>
> --
> .. manuq ..
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



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

Re: [Sugar-devel] Features: Background image in Home View

[Manuel Quiñones]

2013/3/25 Martin Langhoff :
> On Mon, Mar 25, 2013 at 11:48 AM, Manuel Quiñones  wrote:
>> My first impression is that this feature can potentially hurt the
>> clean design of Sugar at some points:
>>
>> - the icons color semantic
>> - high contrast, accesibility
>
> Agreed. IMHO it can be improved by applying a "washout" -- mix the
> image with a white image at 50% alpha.

Great, a washout is a simple and effective solution to my concerns.
We can play with the percentage of white to get the best value.  I
feel 60-70% could be better.

>> I would like to know more about why is this a long requested feature,
>
> Identity is a strong human urge. Kids put stickers on them, adults buy
> cars of different colors :-)

You are right, and I have to say I love the art intervention kids do
with stickers.  I was wondering if the home background was the right
place.  Sounds like a valid reason.

>> - Adding it only in the home view kills the ilussion of having three
>> zoom views.  The background should be displayed in all three, I think.
>
> +1

Ideally the background could do a subtle zoom to better enhace the
illussion.  Would require hardware acceleration though.  Could be left
for future enhacement.

>
>> - Why it needs a restart?
>
> +1
>
>
>
>
> m
> --
>  martin.langh...@gmail.com
>  -  ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  ~ http://docs.moodle.org/24/en/User:Martin_Langhoff



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

Re: [Sugar-devel] [ASLO] Release Pukllanapac-10

[Walter Bender]

On Mon, Mar 25, 2013 at 11:52 AM, Kalpa Welivitigoda
 wrote:
>
>
>
> On Mon, Mar 25, 2013 at 8:39 PM, Sugar Labs Activities
>  wrote:
>>
>> Activity Homepage:
>> http://activities.sugarlabs.org/addon/4320
>>
>> Sugar Platform:
>> 0.82 - 0.98
>>
>> Download Now:
>> http://activities.sugarlabs.org/downloads/file/28530/pukllanapac-10.xo
>>
>> Release notes:
>> 10
>>
>> ENHANCEMENT:
>> * New translations
>>
>
> We already have version 11. Shouldn't this be version 12?

Let me check... somehow my local repository seems behind.

thx

-walter
>
>>
>>
>> Sugar Labs Activities
>> http://activities.sugarlabs.org
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
>
> --
> Best Regards,
>
> Kalpa Welivitigoda
> Junior Treasurer | Electrical Engineering Society
> Undergraduate | Department of Electrical Engineering
> University of Moratuwa
> Sri Lanka
> http://about.me/callkalpa
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



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

Re: [Sugar-devel] Features: Background image in Home View

[Martin Langhoff]

On Mon, Mar 25, 2013 at 11:48 AM, Manuel Quiñones  wrote:
> My first impression is that this feature can potentially hurt the
> clean design of Sugar at some points:
>
> - the icons color semantic
> - high contrast, accesibility

Agreed. IMHO it can be improved by applying a "washout" -- mix the
image with a white image at 50% alpha.

> I would like to know more about why is this a long requested feature,

Identity is a strong human urge. Kids put stickers on them, adults buy
cars of different colors :-)

> - Adding it only in the home view kills the ilussion of having three
> zoom views.  The background should be displayed in all three, I think.

+1

> - Why it needs a restart?

+1




m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/24/en/User:Martin_Langhoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Features: Background image in Home View

[Manuel Quiñones]

Counter-proposal:  add tiled backgrounds

Mockup: http://dev.laptop.org/~manuq/bg-mockup.png

- let the user select a shape (star, football, animal footsteps, etc)
- the color of the shapes is selected by Sugar as the opposite to the
XO colors and very light, almost white.  (Knowledge on Munsell colors
is required to develop it)

Future:

- add a Shapes activity to design the shapes.

What do you think?  Of course, we'll need developer hands for this.

2013/3/25 Manuel Quiñones :
> Testing the latest patch..
>
> 2013/3/25 Gonzalo Odiard :
>> Good catch.
>>
>> Replaced by the more pythonic:
>>
>> def _update_background_image(self, *args):
>> self._background_pixbuf = None
>> if BACKGROUND_IMAGE_PATH and os.path.exists(BACKGROUND_IMAGE_PATH):
>> try:
>>
>> Gonzalo
>
> My first impression is that this feature can potentially hurt the
> clean design of Sugar at some points:
>
> - the icons color semantic
> - high contrast, accesibility
>
> I would like to know more about why is this a long requested feature,
> who requests for it.  I suspect the requirement could come from people
> who is used to conventional PCs, not from kids whos first interaction
> with a computer is the XO.
>
> From the wiki page, I can't distinguish the good background examples
> from the bad ones.  All look preety obstrusive to me.  In fact I can't
> think how a good background could be.  Its colors should be far from
> the grey outline, and far from the user colors too.  And the main
> problem is that the user colors are different for each user, so a
> background that works for a user could not work for the others.  In
> case including this, a good testing contest could be: given a
> background, provide the XO colors that make it fail.
>
> In case we have concensus including this, I have noticed that:
>
> - Adding it only in the home view kills the ilussion of having three
> zoom views.  The background should be displayed in all three, I think.
>
> - I see the home view is not correctly aligned in the vertical axis.
>
> - Why it needs a restart?
>
> Cheers,
>
> --
> .. manuq ..



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

Re: [Sugar-devel] [ASLO] Release Pukllanapac-10

[Kalpa Welivitigoda]

On Mon, Mar 25, 2013 at 8:39 PM, Sugar Labs Activities <
activit...@sugarlabs.org> wrote:

> Activity Homepage:
> http://activities.sugarlabs.org/addon/4320
>
> Sugar Platform:
> 0.82 - 0.98
>
> Download Now:
> http://activities.sugarlabs.org/downloads/file/28530/pukllanapac-10.xo
>
> Release notes:
> 10
>
> ENHANCEMENT:
> * New translations
>
>
We already have version 11. Shouldn't this be version 12?


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



-- 
Best Regards,

Kalpa Welivitigoda
Junior Treasurer | Electrical Engineering Society
Undergraduate | Department of Electrical Engineering
University of Moratuwa
Sri Lanka
http://about.me/callkalpa
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Features: Background image in Home View

[Manuel Quiñones]

Testing the latest patch..

2013/3/25 Gonzalo Odiard :
> Good catch.
>
> Replaced by the more pythonic:
>
> def _update_background_image(self, *args):
> self._background_pixbuf = None
> if BACKGROUND_IMAGE_PATH and os.path.exists(BACKGROUND_IMAGE_PATH):
> try:
>
> Gonzalo

My first impression is that this feature can potentially hurt the
clean design of Sugar at some points:

- the icons color semantic
- high contrast, accesibility

I would like to know more about why is this a long requested feature,
who requests for it.  I suspect the requirement could come from people
who is used to conventional PCs, not from kids whos first interaction
with a computer is the XO.

>From the wiki page, I can't distinguish the good background examples
from the bad ones.  All look preety obstrusive to me.  In fact I can't
think how a good background could be.  Its colors should be far from
the grey outline, and far from the user colors too.  And the main
problem is that the user colors are different for each user, so a
background that works for a user could not work for the others.  In
case including this, a good testing contest could be: given a
background, provide the XO colors that make it fail.

In case we have concensus including this, I have noticed that:

- Adding it only in the home view kills the ilussion of having three
zoom views.  The background should be displayed in all three, I think.

- I see the home view is not correctly aligned in the vertical axis.

- Why it needs a restart?

Cheers,

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

[Sugar-devel] [ASLO] Release Paths-17

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4409

Sugar Platform:
0.96 - 0.98

Download Now:
http://activities.sugarlabs.org/downloads/file/28531/paths-17.xo

Release notes:
NEWS
17

ENHACEMENT:
* New translations

BUG FIX:
* Update deprecated sharing code



Sugar Labs Activities
http://activities.sugarlabs.org

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

[Sugar-devel] [ASLO] Release Pukllanapac-10

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4320

Sugar Platform:
0.82 - 0.98

Download Now:
http://activities.sugarlabs.org/downloads/file/28530/pukllanapac-10.xo

Release notes:
10

ENHANCEMENT:
* New translations


Sugar Labs Activities
http://activities.sugarlabs.org

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

Re: [Sugar-devel] webservices patch (again)

[Manuel Quiñones]

2013/3/20 Walter Bender :
> Back in mid-February, Raul and I submitted four patches for review to
> add webservice support to Sugar [1]. There is a corresponding Feature
> Page [2] in the wiki describing our overall goals. The lack of review
> was undoubtedly due to the fact that the Sugar developers were busy
> with the release of 0.98. I've attached just two of the original four
> patches--the ones that directly impact Sugar as opposed to
> extensions--with the hope that these bits can be reviewed independent
> of any specific services. Once these patches are merged, I will follow
> up with the extension patches.
>
> Meanwhile, there has been some progress made on the Facebook service
> [3] and a preliminary Twitter service is also running [4]. And there
> has been some discussion about making a classroom service (for tasks
> such as handing out classroom materials). I do believe this is an
> important direction for Sugar.

I think this icons could benefit the feature:

http://fortawesome.github.com/Font-Awesome/#icons-social

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

[Sugar-devel] [ASLO] Release Sliderule-29

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4222

Sugar Platform:
0.96 - 0.98

Download Now:
http://activities.sugarlabs.org/downloads/file/28528/sliderule-29.xo

Release notes:
29

ENHANCEMENT:
* New translations




Sugar Labs Activities
http://activities.sugarlabs.org

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

[Sugar-devel] [ASLO] Release Nutrition-11

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4555

Sugar Platform:
0.96 - 0.98

Download Now:
http://activities.sugarlabs.org/downloads/file/28527/nutrition-11.xo

Release notes:
NEWS

11

ENHACEMENT:
* New translations


Sugar Labs Activities
http://activities.sugarlabs.org

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

[Sugar-devel] [ASLO] Release Yupana-11

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4533

Sugar Platform:
0.96 - 0.98

Download Now:
http://activities.sugarlabs.org/downloads/file/28526/yupana-11.xo

Release notes:
11

ENHANCEMENT:
* New translations

BUG FIX:
* Remove deprecated sharing code




Sugar Labs Activities
http://activities.sugarlabs.org

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

Re: [Sugar-devel] Proposal on how to speed up patch reviews

[Gonzalo Odiard]

While I agree in theory with all this,
we can improve our actual situation if we look at our resources,
time and people.

* Time: we don't have a schedule, then feature discussion can't start.
We can improve if we have a clear path and start to define what features
will be included in the next cycle. I am sure different players
right now have different ideas of what the next cycle can/should be,
we need a agreement and try to push together.

* People: We don't have enough people really,
and this situation can be temporally more difficult if some maintainer
have by example  a baby :) (to not use the classic "Linus gets hit by a
bus")
As a project, we need take care of the people working with us,
see at the personal situations, and the maintainers should
open the door to more people to be involved if possible.
For a long time, we had only Simon and Sascha doing sugar maintainership,
and was not enough, now we have Simon and Manuq,
and there are too much work to do. I think we should continue
work on trying to get somebody else involved as maintainer.

Gonzalo

On Mon, Mar 25, 2013 at 8:37 AM, Simon Schampijer wrote:

> Hey Daniel,
>
> thanks for the write-up!
>
> It is true that patch review, especially of non-bugfix patches is slow and
> can be sometimes frustrating for all parties involved, the reviewer, the
> maintainer and the submitter.
>
> To improve that situation, I think we have to put some lights on all those
> roles and I think often the situation of the maintainer is not understood
> well enough. I can at least say that we had this discussions for the last
> years in Sugar, with different maintainers and I have seen it happening in
> many other projects as well. It is a known issue, and it is not an easy
> one, never less I think we can improve.
>
> I think there are different kind of patches, let's simplify with 4
> categories:
>
> [bugfix] a bugfix
>
> [feature] a Feature
>
> [feature/UI] a Feature with UI
>
> [cleanup] a cleanup/maintenance
>
> There are different kind of roles in the process and each will act
> differently based on his needs and duties. There are the submitters, the
> reviewers (can be either the maintainer, or someone else from the
> community) and the maintainers. Let's step through the categories and talk
> about the different roles:
>
> [bugfix] A bugfix is the simplest case. The submitter is interested in
> solving the specific issue he is working on. It is not hard to find a
> reviewer or tester. Either someone from the community that has been annoyed
> by the same issue or the maintainer himself because he is interested in
> seeing the issue solved, his interest is a working code base in the end.
> Here it is easy as well for a maintainer to trust another reviewer and
> acknowledge based on his positive review.
>
> In my experience those patches are not laying around for long if there is
> not a technical blocker in the patch itself. Evaluation is relatively easy
> here.
>
>
> [feature] When it gets to Features things get more tricky. For a Feature
> first of all the high level goals are important: what need does the Feature
> address, is it wanted by the community, is the technical approach taken a
> good one, basically the maintainer has to decide if it is worth taking on
> maintainership of this feature or not. In the end it might be him who has
> to deal with arising bug fixes and who is blamed if the software is not a
> solid product.
>
> That might explain a general bigger resistance to features by maintainers.
> How can we help each other to make this a better process?
>
> First of all, it is important to know the high level goals of a feature.
> The feature process [1] in place actually helps in that regard, the
> maintainer can do the evaluation based on the community feedback and the
> high level goals and if those are accepted can do the actual review of the
> code.
>
> Getting approval for a feature does take time, and the review itself often
> as well, this should be counted in as well from all the sides, especially
> when it is the desire to see a specific feature being present in a release.
>
> Setting goals at the beginning of a release and having an accepting
> feature period will help here as well, actually all of this is in place
> already.
>
>
> [feature/UI] All what have been said above applies to the feature that
> adds UI as well. I have separated that item because it adds another
> complexity. We have the UI process for this (as written in the feature
> policy [1]). Basically it adds more care taking of all the roles involved.
>
>
> [cleanup] These are simple as well and can be acknowledged without much
> thinking. In my opinion, maintainers should be able to do those without the
> need of a review, if uncertain or bigger parts are touched they can discuss
> the items with the other maintainers.
>
>
> [1] 
> http://wiki.sugarlabs.org/go/**Features/Policy
>
>
>
> On 03/24/2013 08:30 PM, Daniel Nar

Re: [Sugar-devel] Proposal on how to speed up patch reviews

[Simon Schampijer]

On 03/25/2013 12:46 PM, Walter Bender wrote:

On Mon, Mar 25, 2013 at 7:37 AM, Simon Schampijer  wrote:

Hey Daniel,

thanks for the write-up!

It is true that patch review, especially of non-bugfix patches is slow and
can be sometimes frustrating for all parties involved, the reviewer, the
maintainer and the submitter.

To improve that situation, I think we have to put some lights on all those
roles and I think often the situation of the maintainer is not understood
well enough. I can at least say that we had this discussions for the last
years in Sugar, with different maintainers and I have seen it happening in
many other projects as well. It is a known issue, and it is not an easy one,
never less I think we can improve.

I think there are different kind of patches, let's simplify with 4
categories:

[bugfix] a bugfix

[feature] a Feature

[feature/UI] a Feature with UI

[cleanup] a cleanup/maintenance

There are different kind of roles in the process and each will act
differently based on his needs and duties. There are the submitters, the
reviewers (can be either the maintainer, or someone else from the community)
and the maintainers. Let's step through the categories and talk about the
different roles:

[bugfix] A bugfix is the simplest case. The submitter is interested in
solving the specific issue he is working on. It is not hard to find a
reviewer or tester. Either someone from the community that has been annoyed
by the same issue or the maintainer himself because he is interested in
seeing the issue solved, his interest is a working code base in the end.
Here it is easy as well for a maintainer to trust another reviewer and
acknowledge based on his positive review.

In my experience those patches are not laying around for long if there is
not a technical blocker in the patch itself. Evaluation is relatively easy
here.


[feature] When it gets to Features things get more tricky. For a Feature
first of all the high level goals are important: what need does the Feature
address, is it wanted by the community, is the technical approach taken a
good one, basically the maintainer has to decide if it is worth taking on
maintainership of this feature or not. In the end it might be him who has to
deal with arising bug fixes and who is blamed if the software is not a solid
product.

That might explain a general bigger resistance to features by maintainers.
How can we help each other to make this a better process?

First of all, it is important to know the high level goals of a feature. The
feature process [1] in place actually helps in that regard, the maintainer
can do the evaluation based on the community feedback and the high level
goals and if those are accepted can do the actual review of the code.

Getting approval for a feature does take time, and the review itself often
as well, this should be counted in as well from all the sides, especially
when it is the desire to see a specific feature being present in a release.

Setting goals at the beginning of a release and having an accepting feature
period will help here as well, actually all of this is in place already.


[feature/UI] All what have been said above applies to the feature that adds
UI as well. I have separated that item because it adds another complexity.
We have the UI process for this (as written in the feature policy [1]).
Basically it adds more care taking of all the roles involved.


[cleanup] These are simple as well and can be acknowledged without much
thinking. In my opinion, maintainers should be able to do those without the
need of a review, if uncertain or bigger parts are touched they can discuss
the items with the other maintainers.


[1] http://wiki.sugarlabs.org/go/Features/Policy



On 03/24/2013 08:30 PM, Daniel Narvaez wrote:


Hello,

I think patch reviews are taking too long. It's probably a well known
issue but I will give a couple of examples as a "proof".

Online services patches, unreviewed  for more than one month
http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041808.html
Unreviewed for more than one month



This one is part of the [feature] category. It can be mostly explained with
the maintainers having their heads still in bug fixing for 0.98.

Here applies as well what I said with high level descriptions of features
and the feature process [2].

[2] http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041810.html


For the record, [3], [4] were sent to the devel list within 6 hours of
your request [2] :P


Ahh, excellent. Didn't see them. In any case, was just an example of a 
typical case.


Regards,
   Simon

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

Re: [Sugar-devel] Proposal on how to speed up patch reviews

[Walter Bender]

On Mon, Mar 25, 2013 at 7:37 AM, Simon Schampijer  wrote:
> Hey Daniel,
>
> thanks for the write-up!
>
> It is true that patch review, especially of non-bugfix patches is slow and
> can be sometimes frustrating for all parties involved, the reviewer, the
> maintainer and the submitter.
>
> To improve that situation, I think we have to put some lights on all those
> roles and I think often the situation of the maintainer is not understood
> well enough. I can at least say that we had this discussions for the last
> years in Sugar, with different maintainers and I have seen it happening in
> many other projects as well. It is a known issue, and it is not an easy one,
> never less I think we can improve.
>
> I think there are different kind of patches, let's simplify with 4
> categories:
>
> [bugfix] a bugfix
>
> [feature] a Feature
>
> [feature/UI] a Feature with UI
>
> [cleanup] a cleanup/maintenance
>
> There are different kind of roles in the process and each will act
> differently based on his needs and duties. There are the submitters, the
> reviewers (can be either the maintainer, or someone else from the community)
> and the maintainers. Let's step through the categories and talk about the
> different roles:
>
> [bugfix] A bugfix is the simplest case. The submitter is interested in
> solving the specific issue he is working on. It is not hard to find a
> reviewer or tester. Either someone from the community that has been annoyed
> by the same issue or the maintainer himself because he is interested in
> seeing the issue solved, his interest is a working code base in the end.
> Here it is easy as well for a maintainer to trust another reviewer and
> acknowledge based on his positive review.
>
> In my experience those patches are not laying around for long if there is
> not a technical blocker in the patch itself. Evaluation is relatively easy
> here.
>
>
> [feature] When it gets to Features things get more tricky. For a Feature
> first of all the high level goals are important: what need does the Feature
> address, is it wanted by the community, is the technical approach taken a
> good one, basically the maintainer has to decide if it is worth taking on
> maintainership of this feature or not. In the end it might be him who has to
> deal with arising bug fixes and who is blamed if the software is not a solid
> product.
>
> That might explain a general bigger resistance to features by maintainers.
> How can we help each other to make this a better process?
>
> First of all, it is important to know the high level goals of a feature. The
> feature process [1] in place actually helps in that regard, the maintainer
> can do the evaluation based on the community feedback and the high level
> goals and if those are accepted can do the actual review of the code.
>
> Getting approval for a feature does take time, and the review itself often
> as well, this should be counted in as well from all the sides, especially
> when it is the desire to see a specific feature being present in a release.
>
> Setting goals at the beginning of a release and having an accepting feature
> period will help here as well, actually all of this is in place already.
>
>
> [feature/UI] All what have been said above applies to the feature that adds
> UI as well. I have separated that item because it adds another complexity.
> We have the UI process for this (as written in the feature policy [1]).
> Basically it adds more care taking of all the roles involved.
>
>
> [cleanup] These are simple as well and can be acknowledged without much
> thinking. In my opinion, maintainers should be able to do those without the
> need of a review, if uncertain or bigger parts are touched they can discuss
> the items with the other maintainers.
>
>
> [1] http://wiki.sugarlabs.org/go/Features/Policy
>
>
>
> On 03/24/2013 08:30 PM, Daniel Narvaez wrote:
>>
>> Hello,
>>
>> I think patch reviews are taking too long. It's probably a well known
>> issue but I will give a couple of examples as a "proof".
>>
>> Online services patches, unreviewed  for more than one month
>> http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041808.html
>> Unreviewed for more than one month
>
>
> This one is part of the [feature] category. It can be mostly explained with
> the maintainers having their heads still in bug fixing for 0.98.
>
> Here applies as well what I said with high level descriptions of features
> and the feature process [2].
>
> [2] http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041810.html

For the record, [3], [4] were sent to the devel list within 6 hours of
your request [2] :P

[3] http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041817.html
[4] http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041820.html

>
>
>> Various patches, including automated testing stuff
>> http://lists.sugarlabs.org/archive/sugar-devel/2012-December/041218.html
>> Unreviewed for more than three months
>
>
> This is nearly category 

Re: [Sugar-devel] Proposal on how to speed up patch reviews

[Simon Schampijer]

Hey Daniel,

thanks for the write-up!

It is true that patch review, especially of non-bugfix patches is slow 
and can be sometimes frustrating for all parties involved, the reviewer, 
the maintainer and the submitter.


To improve that situation, I think we have to put some lights on all 
those roles and I think often the situation of the maintainer is not 
understood well enough. I can at least say that we had this discussions 
for the last years in Sugar, with different maintainers and I have seen 
it happening in many other projects as well. It is a known issue, and it 
is not an easy one, never less I think we can improve.


I think there are different kind of patches, let's simplify with 4 
categories:


[bugfix] a bugfix

[feature] a Feature

[feature/UI] a Feature with UI

[cleanup] a cleanup/maintenance

There are different kind of roles in the process and each will act 
differently based on his needs and duties. There are the submitters, the 
reviewers (can be either the maintainer, or someone else from the 
community) and the maintainers. Let's step through the categories and 
talk about the different roles:


[bugfix] A bugfix is the simplest case. The submitter is interested in 
solving the specific issue he is working on. It is not hard to find a 
reviewer or tester. Either someone from the community that has been 
annoyed by the same issue or the maintainer himself because he is 
interested in seeing the issue solved, his interest is a working code 
base in the end. Here it is easy as well for a maintainer to trust 
another reviewer and acknowledge based on his positive review.


In my experience those patches are not laying around for long if there 
is not a technical blocker in the patch itself. Evaluation is relatively 
easy here.



[feature] When it gets to Features things get more tricky. For a Feature 
first of all the high level goals are important: what need does the 
Feature address, is it wanted by the community, is the technical 
approach taken a good one, basically the maintainer has to decide if it 
is worth taking on maintainership of this feature or not. In the end it 
might be him who has to deal with arising bug fixes and who is blamed if 
the software is not a solid product.


That might explain a general bigger resistance to features by 
maintainers. How can we help each other to make this a better process?


First of all, it is important to know the high level goals of a feature. 
The feature process [1] in place actually helps in that regard, the 
maintainer can do the evaluation based on the community feedback and the 
high level goals and if those are accepted can do the actual review of 
the code.


Getting approval for a feature does take time, and the review itself 
often as well, this should be counted in as well from all the sides, 
especially when it is the desire to see a specific feature being present 
in a release.


Setting goals at the beginning of a release and having an accepting 
feature period will help here as well, actually all of this is in place 
already.



[feature/UI] All what have been said above applies to the feature that 
adds UI as well. I have separated that item because it adds another 
complexity. We have the UI process for this (as written in the feature 
policy [1]). Basically it adds more care taking of all the roles involved.



[cleanup] These are simple as well and can be acknowledged without much 
thinking. In my opinion, maintainers should be able to do those without 
the need of a review, if uncertain or bigger parts are touched they can 
discuss the items with the other maintainers.



[1] http://wiki.sugarlabs.org/go/Features/Policy


On 03/24/2013 08:30 PM, Daniel Narvaez wrote:

Hello,

I think patch reviews are taking too long. It's probably a well known
issue but I will give a couple of examples as a "proof".

Online services patches, unreviewed  for more than one month
http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041808.html
Unreviewed for more than one month


This one is part of the [feature] category. It can be mostly explained 
with the maintainers having their heads still in bug fixing for 0.98.


Here applies as well what I said with high level descriptions of 
features and the feature process [2].


[2] http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041810.html


Various patches, including automated testing stuff
http://lists.sugarlabs.org/archive/sugar-devel/2012-December/041218.html
Unreviewed for more than three months


This is nearly category [cleanup]. We should not block here on a in 
depth review when things pass the usual tests (pep8 etc) and the high 
level approach is accepted (taking for granted that the maintainer is 
fixing up the issues that might arise himself).



I think this situation is seriously hurting the project, in several ways:


Agreed.


* It makes hacking on sugar not fun at all. I honestly even lost
interest in the patches I sent at this point.
* It discou

[Sugar-devel] [ASLO] Release Paint-57

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4082

Sugar Platform:
0.98 - 0.98

Download Now:
http://activities.sugarlabs.org/downloads/file/28525/paint-57.xo

Release notes:
Fix ticket SL #4418 - Allow copy images from Browse, and open images in all the 
supported formats.


Sugar Labs Activities
http://activities.sugarlabs.org

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

Re: [Sugar-devel] Features: Background image in Home View

[Gonzalo Odiard]

Good catch.

Replaced by the more pythonic:

def _update_background_image(self, *args):
self._background_pixbuf = None
if BACKGROUND_IMAGE_PATH and os.path.exists(BACKGROUND_IMAGE_PATH):
try:

Gonzalo



On Fri, Mar 22, 2013 at 11:26 PM, Ajay Garg wrote:

> Hi Gonzalo.
>
> Thanks for this awesome feature !!
>
> Just one small issue  :
> I tried it on sugar-build, and sugar failed to start, because
> "BACKGROUND_IMAGE_PATH" was None.
>
> Changing the method "_update_background_image" to
>
> def _update_background_image(self, *args):
> self._background_pixbuf = None
>
> if BACKGROUND_IMAGE_PATH is None:
> return
>
> if os.path.exists(BACKGROUND_IMAGE_PATH):
> try:
> self._background_pixbuf = GdkPixbuf.Pixbuf.new_from_file(
>
> BACKGROUND_IMAGE_PATH)
> self._favorites_eventbox.queue_draw()
> except:
> pass
>
>
>
> does the trick !!!
>
>
>
>
> On Sat, Mar 23, 2013 at 2:22 AM, Gonzalo Odiard wrote:
>
>> Is the way the draw is done in gtk.
>> The eventbox is not a Image where you load a image and then is draw when
>> needed.
>>
>> Gonzalo
>>
>>
>> On Fri, Mar 22, 2013 at 5:42 PM, James Cameron  wrote:
>>
>>> Not a blocking question: but why wait until the draw callback of the
>>> eventbox before calling cairo?  Can this not be done in the widget
>>> creation?
>>>
>>> Reviewed-by: James Cameron 
>>>
>>> --
>>> James Cameron
>>> http://quozl.linux.org.au/
>>> ___
>>> 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
>>
>>
>
>
> --
> Regards,
>
> Ajay Garg
> Dextrose Developer
> Activity Central: http://activitycentral.com


0001-Add-a-section-in-the-control-panel-to-configure-the-.patch
Description: Binary data
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel