Re: [Sugar-devel] Bug tracking Vs Patch review

[Marco Pesenti Gritti]

On 2 Sep 2010, at 21:02, Bernie Innocenti  wrote:
> Let's get started this way. If needed, we could refine the rules later
> on. To avoid confusion, I'd wait updating the documentation in the wiki
> until we've tested this new workflow for a while.
> 
> If a maintainer cannot stand to approve patches submitted to the
> mailing-list, I'd ask them to state it clearly, so we don't needlessly
> disappoint submitters. If a submitter still prefers the old workflow,
> they can keep filing patches in the bug tracker as before.
> 
> Agreed?

Sounds good to me. I would put the notes somewhere on the wiki as 
experimental/unofficial so that we can integrate improvements. 

> 
>> I'm pretty confident we can setup and improve patchwork to help us
>> tracking patch status reliably. I don't have a lot of time but I will
>> commit to help out with both infrastructure and the reviews
>> themselves.
> 
> We've already had Patchwork on this list for a while:
> 
>  http://patchwork.sugarlabs.org/project/sugar/list/
> 
> It's a useful aid on the side, but I don't think it needs to get in the
> middle of the patch workflow. People are generally good at keeping track
> of threads in mailing list within their MUA.

Some people are, some are less, included our most active maintainer :) I think 
we agree about patchwork being an additional tool anyway.

> In case a patch gets overlooked by the maintainer, the submitter can
> resend it after a while. If even the submitter forgets, someone else
> could ping. If nobody cares to ping, it means that patch wasn't very
> interesting after all.

This is a bit simplistic. The submitter might just think we don't care and stop 
submitting patches.  Let's forget about that for now though, we need to make 
this work well for the existing contributors before we even start thinking 
about involving more.

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

Re: [Sugar-devel] Patch review, combining/splitting modules (was: Re: Patch review)

[Marco Pesenti Gritti]

On 2 Sep 2010, at 21:21, Sascha Silbe  
wrote:
> BTW, I've recently changed my mind on the repo-combining: We should work
> on splitting up our code, not combine it in a single repo. Our modules
> are too tightly coupled; sometimes even "from foo import bar" doesn't
> work (cyclic dependencies?). Let's factor out stuff like
> 
> - "Sugarised" / "improved" widgets (most of sugar.graphics?)
> - API wrappers (e.g. sugar.datastore.datastore)
> - Activity framework
> 
> and make them as self-contained as possible, with a layering approach.
> E.g. the activity framework would use the API wrappers, but the API
> wrappers would not depend (w.r.t. code) on anything else. The widgets
> also wouldn't depend on anything else; the Object Chooser widget
> should be in the Journal and the code to invoke it (currently
> sugar.graphics.objectchooser) should be in the API wrappers package.

Splitting in different packages can be helpful to mark more strongly the 
separation between components, but it's neither necessary nor sufficient to 
ensure proper modularity and decoupling. Our codebase is so tiny... 
Dependencies can be expressed just fine by the directories structure, without 
having to pay the maintenance and complexity costs of a gazillions of small 
packages.  

> As I gather from recent threads on sugar-devel Gnome will force some
> incompatibilities on us for Sugar 0.92 anyway, so now is a good time
> to do this split (as it will break API).

It's definitely a very good time to cleanup our API. Improving modularity would 
be awesome but I disagree it requires splitting packages even more.

> My hope is that having a separate list might lower the barrier of
> posting to it. People might feel more comfortable about posting
> unfinished / hacky stuff if there's a dedicated list for it instead of
> getting "exposed" on the main list. I don't know if it actually is a
> problem currently, but it's worth a try.

I would make damn sure we have a problem before considering to complicate 
processes and create new mailing lists because of it.

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

Re: [Sugar-devel] Bug tracking Vs Patch review

[James Cameron]

Sascha Silbe wrote:
> Bernie wrote:
> > 1) On the submitter end:
> > git commit -s
> > git format-patch -1
> > git send-email --to maintainer --cc list foo.patch
> 
> In case the patch closes a bug in Trac, submitter includes the ticket
> reference in the subject.
> 
> keyboard cpsection: don't choke on option group (SL#2022)

I'm in agreement with the proposal by Bernie and Sascha.

Regarding how to identify maintainers' patch submission preferences, I
suggest this could be added to a MAINTAINERS file in each repository.
While this information may be redundant, it would help new developers,
and would be maintained along with the source rather than in a separate
place.

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

Re: [Sugar-devel] [Dextrose] Stability stuff

[Bernie Innocenti]

El Thu, 02-09-2010 a las 09:26 -0400, Martin Abente escribió:
> Weird, I really tried to trigger it on our last Dextrose build and never
> happened.

Perhaps it's gone, but I have not done anything to fix it. The bug seems
to be in Pytrhon, dbus or their dependencies.


> The whole idea of killing activities is a little bit controversial I
> think, you have to assume to many things about activities, so far just a
> few activities in sugar uses all the proper mechanisms, I am afraid that in
> most of the cases kids would just loose their current work.

I thought almost all activities understood the protocol for quitting
cleanly (probably a dbus message). You can test it by clicking Stop from
the menu on the icons top of the frame. That wouldn't work without
sending an IPC message of some kind (probably we use dbus because we
can't stand to use established X11 standards to manage applications).


> What about... If the system load is already close to a "critical" point,
> SUGAR could just stop new activities from being executed with a proper
> warning, and suggestions.

This is also a very good suggestion. We could start by doing this, which
is a lot easier and almost equally effective.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

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

[Sugar-devel] [PATCH] Build Squeak VM 4.0.3 from tarfile

[Bert Freudenberg]

This is almost the same as my patch from April, which never made it in.
Instead of building from the outdated "olpc" subversion branch, the Squeak VM 
is build from a release tarball.
It adds a cmake dependency, and gives an error if make is run without running 
autogen.sh first.
Also adds a "clean" make target to please jhbuild.

Signed-off-by: Bert Freudenberg 
---
 config/modulesets/glucose-external.modules  |   15 +++-
 config/modulesets/patches/squeak-autogen.patch  |   28 +++
 config/modulesets/patches/squeak-makefile.patch |   11 +
 config/sysdeps/debian-family.xml|1 +
 config/sysdeps/fedora-family.xml|1 +
 config/sysdeps/mandrivalinux-2009.1.xml |1 +
 6 files changed, 51 insertions(+), 6 deletions(-)
 create mode 100644 config/modulesets/patches/squeak-autogen.patch
 create mode 100644 config/modulesets/patches/squeak-makefile.patch

diff --git a/config/modulesets/glucose-external.modules 
b/config/modulesets/glucose-external.modules
index d76b1f0..0577963 100644
--- a/config/modulesets/glucose-external.modules
+++ b/config/modulesets/glucose-external.modules
@@ -5,8 +5,8 @@
   href="git://dev.laptop.org/projects/" />
   
-  http://squeakvm.org/svn/squeak/branches/"; trunk-template="olpc"/>
+  http://squeakvm.org/unix/release/"/>
   
   
 
   
-  
-
-
-
+  
+
+  
+  
+
   
   
 
diff --git a/config/modulesets/patches/squeak-autogen.patch 
b/config/modulesets/patches/squeak-autogen.patch
new file mode 100644
index 000..ff9274d
--- /dev/null
+++ b/config/modulesets/patches/squeak-autogen.patch
@@ -0,0 +1,28 @@
+--- /dev/null  2010-09-02 18:58:30.359785873 +0200
 autogen.sh 2010-09-02 22:07:35.577316348 +0200
+@@ -0,0 +1,25 @@
++#!/bin/sh
++EXCLUDE="gl FileCopyPlugin SqueakFFIPrims B3DAcceleratorPlugin 
PseudoTTYPlugin UnixOSProcessPlugin XDisplayControlPlugin"
++
++test -d bld || mkdir bld
++
++OPTIONS=""
++for p in $EXCLUDE ; do
++  OPTIONS="$OPTIONS --without-${p}"
++done
++
++(cd bld && ../unix/cmake/configure $OPTIONS "$@")
++
++cat > Makefile <<__EOF__
++default:
++  make -C bld
++
++install:
++  make -C bld install
++
++check:
++  @echo SKIPPED: No tests defined for Squeak VM
++
++clean:
++  rm -rf bld Makefile
++__EOF__
diff --git a/config/modulesets/patches/squeak-makefile.patch 
b/config/modulesets/patches/squeak-makefile.patch
new file mode 100644
index 000..043dc7d
--- /dev/null
+++ b/config/modulesets/patches/squeak-makefile.patch
@@ -0,0 +1,11 @@
+--- Makefile.orig  2010-09-02 22:11:03.702191222 +0200
 Makefile   2010-09-02 22:21:14.580177789 +0200
+@@ -1,7 +1,5 @@
+ all : .force
+-  test -d bld || mkdir bld
+-  (cd bld; ../unix/cmake/configure)
+-  (cd bld; make)
++  @test -d bld || (echo ERROR: run autogen.sh first; exit 1)
+ 
+ install : all
+   (cd bld; make install)
diff --git a/config/sysdeps/debian-family.xml b/config/sysdeps/debian-family.xml
index ce11329..9870451 100644
--- a/config/sysdeps/debian-family.xml
+++ b/config/sysdeps/debian-family.xml
@@ -3,6 +3,7 @@
   
   
   
+  
   
   
   
diff --git a/config/sysdeps/fedora-family.xml b/config/sysdeps/fedora-family.xml
index 83ec629..f97efb4 100644
--- a/config/sysdeps/fedora-family.xml
+++ b/config/sysdeps/fedora-family.xml
@@ -7,6 +7,7 @@
   
   
   
+  
   
   
   
diff --git a/config/sysdeps/mandrivalinux-2009.1.xml 
b/config/sysdeps/mandrivalinux-2009.1.xml
index 0acac46..7fa1131 100644
--- a/config/sysdeps/mandrivalinux-2009.1.xml
+++ b/config/sysdeps/mandrivalinux-2009.1.xml
@@ -9,6 +9,7 @@
   
   
   
+  
   
   
   
-- 
1.7.2.2


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

Re: [Sugar-devel] Bug tracking Vs Patch review

[Bert Freudenberg]

On 02.09.2010, at 23:28, Bert Freudenberg wrote:

> 
> On 02.09.2010, at 22:46, Sascha Silbe wrote:
> 
>> Excerpts from Bernie Innocenti's message of Thu Sep 02 22:02:29 +0200 2010:
>> 
>>> 1) On the submitter end:
>>> 
>>>   git commit -s
>>>   git format-patch -1
>>>   git send-email --to maintainer --cc list foo.patch
>> 
>> Just one amendment: 
>> 
>> In case the patch closes a bug in Trac, submitter includes the ticket
>> reference in the subject. E.g.
>> 
>> keyboard cpsection: don't choke on option group (SL#2022)
>> 
>> 
>> Otherwise +1.
> 
> On Fedora 13, git-send-email is not requires by sugar-jhbuild. If this is the 
> official way to submit patches, then "git-email" should be added to sysdeps.
> 
> - Bert -

Also, mail sent this way gets blocked, see below. I'll send it again using my 
regular mailer.

- Bert -

>From mailer-dae...@fedora13.localdomain  Thu Sep  2 23:37:17 2010
Return-Path: 
Received: from localhost (localhost)
by fedora13.localdomain (8.14.4/8.14.4) id o82LbHmW020736;
Thu, 2 Sep 2010 23:37:17 +0200
Date: Thu, 2 Sep 2010 23:37:17 +0200
From: Mail Delivery Subsystem 
Message-Id: <201009022137.o82lbhmw020...@fedora13.localdomain>
To: 
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="o82LbHmW020736.1283463437/fedora13.localdomain"
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)

This is a MIME-encapsulated message

--o82LbHmW020736.1283463437/fedora13.localdomain

The original message was received at Thu, 2 Sep 2010 23:37:04 +0200
from fedora13.localdomain [127.0.0.1]

   - The following addresses had permanent fatal errors -

(reason: 550 Dial-Up IP address rejected)

(reason: 554 5.7.1 Service unavailable; Client host [77.184.213.183] 
blocked using zen.spamhaus.org; 
http://www.spamhaus.org/query/bl?ip=77.184.213.183)

(reason: 517-Domain does not exist: fedora13.localdomain.)

   - Transcript of session follows -
... while talking to mailin.rzone.de.:
>>> DATA
<<< 550 Dial-Up IP address rejected
550 5.1.1 ... User unknown
<<< 554 5.0.0 no valid recipients given
... while talking to solarsail.sugarlabs.org.:
>>> DATA
<<< 554 5.7.1 Service unavailable; Client host [77.184.213.183] blocked using 
zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=77.184.213.183
554 5.0.0 Service unavailable
<<< 554 5.5.1 Error: no valid recipients
... while talking to b.mx.chost.de.:
>>> MAIL From: SIZE=5977
<<< 517-Domain does not exist: fedora13.localdomain.
<<< 517 Invalid domain, see ftp://ftp.isi.edu/in-notes/rfc1035.txt>
554 5.0.0 Service unavailable

--o82LbHmW020736.1283463437/fedora13.localdomain
Content-Type: message/delivery-status

Reporting-MTA: dns; fedora13.localdomain
Received-From-MTA: DNS; fedora13.localdomain
Arrival-Date: Thu, 2 Sep 2010 23:37:04 +0200

Final-Recipient: RFC822; b...@freudenbergs.de
Action: failed
Status: 5.1.1
Remote-MTA: DNS; mailin.rzone.de
Diagnostic-Code: SMTP; 550 Dial-Up IP address rejected
Last-Attempt-Date: Thu, 2 Sep 2010 23:37:05 +0200

Final-Recipient: RFC822; sugar-devel@lists.sugarlabs.org
Action: failed
Status: 5.7.1
Remote-MTA: DNS; solarsail.sugarlabs.org
Diagnostic-Code: SMTP; 554 5.7.1 Service unavailable; Client host 
[77.184.213.183] blocked using zen.spamhaus.org; 
http://www.spamhaus.org/query/bl?ip=77.184.213.183
Last-Attempt-Date: Thu, 2 Sep 2010 23:37:08 +0200

Final-Recipient: RFC822; sas...@silbe.org
Action: failed
Status: 5.0.0
Diagnostic-Code: SMTP; 517-Domain does not exist: fedora13.localdomain.
Last-Attempt-Date: Thu, 2 Sep 2010 23:37:17 +0200

--o82LbHmW020736.1283463437/fedora13.localdomain
Content-Type: message/rfc822

Return-Path: 
Received: from fedora13.localdomain (fedora13.localdomain [127.0.0.1])
by fedora13.localdomain (8.14.4/8.14.4) with ESMTP id o82Lb3mW020734;
Thu, 2 Sep 2010 23:37:04 +0200
Received: (from b...@localhost)
by fedora13.localdomain (8.14.4/8.14.4/Submit) id o82Lb1DR020733;
Thu, 2 Sep 2010 23:37:01 +0200
From: Bert Freudenberg 
To: sas...@silbe.org
Cc: sugar-devel@lists.sugarlabs.org, Bert Freudenberg 
Subject: [PATCH] Build Squeak VM 4.0.3 from tarfile
Date: Thu,  2 Sep 2010 23:36:17 +0200
Message-Id: <1283463377-20677-1-git-send-email-b...@freudenbergs.de>
X-Mailer: git-send-email 1.7.2.2

This is almost the same as my patch from April, which never made it in.
Instead of building from the outdated "olpc" subversion branch, the Squeak VM 
is build from a release tarball.
It adds a cmake dependency, and gives an error if make is run without running 
autogen.sh first.
Also adds a "clean" make target to please jhbuild.

Signed-off-by: Bert Freudenberg 
---
 config/modulesets/glucose-external.modules  |   15 +++-
 config/modulesets/patches/squeak-autogen.patch  |   28 +++
 config/modulesets/patches/squeak-makefile.patch |   11 +
 config/sysdeps/debian-family.xml|1 +
 config/sys

Re: [Sugar-devel] [olpc-nz] Twi translation

[tom]

On Fri, September 3, 2010 9:32 am, Brenda Wallace wrote:
> We have 2 volunteers coming tomorrow who are fluent in Tagalog (and a
> half dozen other languages) - Where do i look to find status of
> translations for the Philippines? Is there someone I can co-ordinate
> with? Where can they help most?

The status of all languages can be found at http://translate.sugarlabs.org/

If the language is not on the list there or a project is missing from a
language, then it needs to be added by the administrators. We had most
"luck" raising a ticket and then updating the ticket with requests for
action when they weren't actioned.

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

[Sugar-devel] [SoaS] Activities not starting on groupinstall sugar-desktop with on HD installed f14-Alpha-DVD.

[Thomas C Gilliard]

FYI:
I just completed a  groupinstall sugar-desktop on an 8 GB USB installed 
with the  f14-Alpha-DVD


this included the extra x64  14.07.noarch anaconda repo. after asking 
for permission during install
0.89.6 sugar and 0.90 presence were installed

 >Starts: Etoys 115
 >Fails to start with pop up box: log-23; write 69; record 66; IRC 6; 
chat 66; terminal 31; Turtle Blocks 92; Browse 117; read 79; Physics 5
 > CP shows: sugar 0.89.3 f14-branched

All activities are in /usr/share/sugar/activities

there is no Activities directory located in /home/(user)

I see the new 3AD-hoc wireless AP's in f1 neighborhood and the Journal 
sort icon on the top frame

This same behavior, of activities not starting, occurs in sugar-emulator 
and a gdm chosen sugar.

Tom Gilliard
satellit



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

Re: [Sugar-devel] Bug tracking Vs Patch review

[Bert Freudenberg]

On 02.09.2010, at 22:46, Sascha Silbe wrote:

> Excerpts from Bernie Innocenti's message of Thu Sep 02 22:02:29 +0200 2010:
> 
>> 1) On the submitter end:
>> 
>>git commit -s
>>git format-patch -1
>>git send-email --to maintainer --cc list foo.patch
> 
> Just one amendment: 
> 
> In case the patch closes a bug in Trac, submitter includes the ticket
> reference in the subject. E.g.
> 
> keyboard cpsection: don't choke on option group (SL#2022)
> 
> 
> Otherwise +1.

On Fedora 13, git-send-email is not requires by sugar-jhbuild. If this is the 
official way to submit patches, then "git-email" should be added to sysdeps.

- Bert -


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

[Sugar-devel] SUGAR_PROFILE feature, slimming down sugar-jhbuild (was: [PATCH] Make building GConf-dbus optional)

[Sascha Silbe]

Excerpts from Bernie Innocenti's message of Thu Sep 02 19:27:59 +0200 2010:

> Compiling this module frequently breaks, resulting in difficulties for
> novice developers and waste of time for everyone else.

The only reason I still haven't removed GConf-dbus is that I lack
patches for the _documentation_, not the code.
We explain how to use SUGAR_PROFILE to run multiple instances of Sugar
in parallel, but not how to do the same using multiple OS-level user
accounts.

As soon as somebody updates the wiki with a good HowTo, I will kick
GConf-dbus out of sugar-jhbuild with *delight*. :)

In general any help with removing packages from sugar-jhbuild is
welcome. A good starting point would be to create backports of the very
latest Telepathy packages for the supported distros.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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

Re: [Sugar-devel] sugar broken in F14? (was Re: Bug tracking Vs Patch review)

[Sascha Silbe]

Excerpts from Tomeu Vizoso's message of Thu Sep 02 10:44:35 +0200 2010:

> I alone won't find all the issues so if you (and others) can file the
> bugs you find, I will be able to fix them faster.
I sure will look for, find and report more bugs after you fixed the
blocker one [1] that prevents me from testing. :-P

BTW: Thanks for working on this!

Sascha

[1] https://bugs.sugarlabs.org/ticket/2217
--
http://sascha.silbe.org/
http://www.infra-silbe.de/


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

Re: [Sugar-devel] Bug tracking Vs Patch review

[Gonzalo Odiard]

The ticket must be closed in Trac when the code its commited?

Gonzalo


On Thu, Sep 2, 2010 at 5:46 PM, Sascha Silbe <
sascha-ml-reply-to-201...@silbe.org> wrote:

> Excerpts from Bernie Innocenti's message of Thu Sep 02 22:02:29 +0200 2010:
>
> > 1) On the submitter end:
> >
> > git commit -s
> > git format-patch -1
> > git send-email --to maintainer --cc list foo.patch
>
> Just one amendment:
>
> In case the patch closes a bug in Trac, submitter includes the ticket
> reference in the subject. E.g.
>
> keyboard cpsection: don't choke on option group (SL#2022)
>
>
> Otherwise +1.
>
> Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Gonzalo Odiard
Responsable de Desarrollo (pasando la antorcha...)
Sistemas Australes
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Bug tracking Vs Patch review

[Sascha Silbe]

Excerpts from Bernie Innocenti's message of Thu Sep 02 22:02:29 +0200 2010:

> 1) On the submitter end:
> 
> git commit -s
> git format-patch -1
> git send-email --to maintainer --cc list foo.patch

Just one amendment: 

In case the patch closes a bug in Trac, submitter includes the ticket
reference in the subject. E.g.

keyboard cpsection: don't choke on option group (SL#2022)


Otherwise +1.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


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

[Sugar-devel] Patch review, combining/splitting modules (was: Re: Patch review)

[Sascha Silbe]

Excerpts from Tomeu Vizoso's message of Thu Sep 02 18:33:51 +0200 2010:

[repo to push to after review, for maintainers to choose from]
> > We could rebase after each release, like (at least some of) the Linux
> > folks are doing. Either on the master branch, or by creating a new
> > branch for each release (like the OLPC kernel repo).
> 
> Sounds good.

OK, to get this started, I cloned the repositories of sugar-artwork,
sugar-base, sugar-datastore, sugar-toolkit and sugar. For lack of a
better name, I chose "next". Let's start with the rebasing approach
(i.e. use the "master" branch); we can switch to the branch model if it
turns out that rebasing causes too much of a headache.

Will go through Patchwork and check for any patches of mine that have
enough Reviewed-By to push them.

BTW, I've recently changed my mind on the repo-combining: We should work
on splitting up our code, not combine it in a single repo. Our modules
are too tightly coupled; sometimes even "from foo import bar" doesn't
work (cyclic dependencies?). Let's factor out stuff like

- "Sugarised" / "improved" widgets (most of sugar.graphics?)
- API wrappers (e.g. sugar.datastore.datastore)
- Activity framework

and make them as self-contained as possible, with a layering approach.
E.g. the activity framework would use the API wrappers, but the API
wrappers would not depend (w.r.t. code) on anything else. The widgets
also wouldn't depend on anything else; the Object Chooser widget
should be in the Journal and the code to invoke it (currently
sugar.graphics.objectchooser) should be in the API wrappers package.

As I gather from recent threads on sugar-devel Gnome will force some
incompatibilities on us for Sugar 0.92 anyway, so now is a good time
to do this split (as it will break API).

Obviously the catch is that somebody will have to do the work of
analysing the source code, deciding on good split points (i.e. new
packages) and implement it...

> I for one liked having patch submission and reviews in the same
> channel as we discuss other development stuff. But will subscribe to
> another mailing list if needed.

My hope is that having a separate list might lower the barrier of
posting to it. People might feel more comfortable about posting
unfinished / hacky stuff if there's a dedicated list for it instead of
getting "exposed" on the main list. I don't know if it actually is a
problem currently, but it's worth a try.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


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

Re: [Sugar-devel] sugar broken in F14?

[Bernie Innocenti]

El Thu, 02-09-2010 a las 10:44 +0200, Tomeu Vizoso escribió:

> I'm testing daily the Sugar 0.90 packages that Peter (big thanks!) is
> doing on F14 and the tarballs that you see I'm making are intended to
> fix issues I find there. I'm still updating, but as of yesterday Sugar
> was starting correctly and I couldn't find any major issues.

Still broken here. I have F14 fully updated, plus the Sugar packages
from updates-testing. If I remove ~/.sugar, I get to see the color
selection screen before Sugar dies.

Do you have any other non-standard rpms installed? Any other environment
tweaks?


> I alone won't find all the issues so if you (and others) can file the
> bugs you find, I will be able to fix them faster.

I've already filed 2... one happened to be yet another GConf-dbus issue,
the other one still stands:

  http://bugs.sugarlabs.org/ticket/2269

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

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

Re: [Sugar-devel] Bug tracking Vs Patch review

[Bernie Innocenti]

El Wed, 01-09-2010 a las 23:43 +0100, Marco Pesenti Gritti escribió:

> We agree that we should try out reviews on the mailing list, let's
> just do it.

If Tomeu is ok with it, I'll repost some of my old patches to the list
to get them reviewed and, hopefully, approved.

To recap, the submission rules I propose are really simple:

1) On the submitter end:

git commit -s
git format-patch -1
git send-email --to maintainer --cc list foo.patch

2) Anyone who sees the patch can reply with inline comments
   Multiple reviews are welcome.

3) The reviewer can conclude the message with one of these tags:

Acked-by: Joe Hacker 
Reviewed-by: Joe Hacker 
Tested-by: Joe Hacker 

   Only module maintainers and peers can ack a patch.
   The meaning of these tags should be already self-explanatory.
   In case someone has doubts, here's the full explanation:
   http://lxr.linux.no/linux/Documentation/SubmittingPatches

4) if submitter has write access to the repository, he/she amends
   the patch, appending any collected tags to it:

 git commit --amend
 git push

   (submitters with multiple patches in their queue may need to
   rebase or switch to a clean branch)

5) in case the patch closes a bug in Trac, submitter closes the
   bug mentioning the commit ID as usual

Let's get started this way. If needed, we could refine the rules later
on. To avoid confusion, I'd wait updating the documentation in the wiki
until we've tested this new workflow for a while.

If a maintainer cannot stand to approve patches submitted to the
mailing-list, I'd ask them to state it clearly, so we don't needlessly
disappoint submitters. If a submitter still prefers the old workflow,
they can keep filing patches in the bug tracker as before.

Agreed?


> I'm pretty confident we can setup and improve patchwork to help us
> tracking patch status reliably. I don't have a lot of time but I will
> commit to help out with both infrastructure and the reviews
> themselves.

We've already had Patchwork on this list for a while:

  http://patchwork.sugarlabs.org/project/sugar/list/

It's a useful aid on the side, but I don't think it needs to get in the
middle of the patch workflow. People are generally good at keeping track
of threads in mailing list within their MUA.

In case a patch gets overlooked by the maintainer, the submitter can
resend it after a while. If even the submitter forgets, someone else
could ping. If nobody cares to ping, it means that patch wasn't very
interesting after all.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

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

Re: [Sugar-devel] Bug tracking Vs Patch review

[Sascha Silbe]

Excerpts from Marco Pesenti Gritti's message of Thu Sep 02 00:43:14 +0200 2010:

> I'm pretty confident we can setup and improve patchwork to help us tracking 
> patch status reliably. I don't have a lot of time but I will commit to help 
> out with both infrastructure and the reviews themselves.

Thanks!

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


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

Re: [Sugar-devel] Patch review (was: Re: Community)

[Marco Pesenti Gritti]

I agree. Two major advantages of reviews are higher visibility and a
process which is really easy to explain, we should not lose them.

Marco

On 9/2/10, Tomeu Vizoso  wrote:
> On Thu, Sep 2, 2010 at 18:28, Sascha Silbe
>  wrote:
>> Excerpts from Tomeu Vizoso's message of Tue Aug 31 13:20:31 +0200 2010:
>>
>>> > What do you think about a model where we have some git repo that
>>> > everyone can commit to after they got, say, at least two Reviewed-By
>>> > (including one from a core / "long"-term developer)? The contributors
>>> > would get more testing of their work (=> less bugs in the release) and
>>> > the module maintainers would be able to pick resp. skip the patches
>>> > they
>>> > feel (un)comfortable with.
>>>
>>> But then we would need to resync at some point or merging would get
>>> worst with time?
>>
>> We could rebase after each release, like (at least some of) the Linux
>> folks are doing. Either on the master branch, or by creating a new
>> branch for each release (like the OLPC kernel repo).
>
> Sounds good.
>
>>> > Another idea would be a mailing list where early versions of patches
>>> > are
>>> > posted and can get some (incomplete) review. This would allow
>>> > contributors to get fast & easy feedback with a limited amount of time
>>> > spent for the reviewers. Reviews could just point out a subset of
>>> > issues;
>>> > a thorough review and deciding whether it's good enough to be merged
>>> > would happen like above.
>>>
>>> I liked how it worked in sugar-devel for a while, a separate mailing
>>> list would be also ok if the reviews do disturb people or whatever is
>>> the reason for having stopped doing that.
>>
>> To make it clear: Both the new mailing list and sugar-devel would carry
>> reviews. The difference is that RFC / PoC style patches would land on
>> the new mailing list, whereas those intended to get into mainline as-is
>> would be on sugar-devel.
>>
>> This would give a clear indication about whether a patch is intended
>> for mainline and also keep the "newbie" traffic off sugar-devel (IIRC
>> some people have complained about the high traffic on sugar-devel).
>>
>> The drawback is that we might miss some feedback from people who only
>> subscribe to sugar-devel but not to the new list. But then those are
>> probably the same people that would have complained about the increased
>> traffic. ;)
>>
>> An alternative would be to clearly mark patches with e.g. "RFC" in the
>> subject and create mailing list topics to allow filtering out review
>> related traffic. We already have "[ANNOUNCE]" and "[RELEASE]" topics
>> to allow anyone to receive only important announcements. The drawback
>> of this alternative is that few users notice this option and might
>> unsubscribe instead of activating the topic filter.
>
> I for one liked having patch submission and reviews in the same
> channel as we discuss other development stuff. But will subscribe to
> another mailing list if needed.
>
> Regards,
>
> Tomeu
>
>> Sascha
>>
>> --
>> http://sascha.silbe.org/
>> http://www.infra-silbe.de/
>>
>> ___
>> 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
>

-- 
Sent from my mobile device
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH] Make building GConf-dbus optional

[Bernie Innocenti]

Compiling this module frequently breaks, resulting in difficulties for
novice developers and waste of time for everyone else.

This patch simply makes GConf-dbus an optional compilation unit. If
there's some consensus, I could follow up with a more aggressive patch
removing it althogether.

GConf-dbus is unmaintained and is no longer part of any Linux
distribution. It was used to support multiple Sugar profiles within
the same UNIX user, a feature of dubious usefulness that could be used
to test collaboration without creating multiple accounts.

Signed-off-by: Bernie Innocenti 
---
 config/modulesets/glucose-0.84.modules   |1 -
 config/modulesets/glucose-versionsupport.modules |1 -
 config/modulesets/glucose.modules|1 -
 3 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/config/modulesets/glucose-0.84.modules 
b/config/modulesets/glucose-0.84.modules
index 9d7e1cd..005988e 100644
--- a/config/modulesets/glucose-0.84.modules
+++ b/config/modulesets/glucose-0.84.modules
@@ -21,7 +21,6 @@
   
 
 
-  
   
   
   
diff --git a/config/modulesets/glucose-versionsupport.modules 
b/config/modulesets/glucose-versionsupport.modules
index a26c8a6..372ddc0 100644
--- a/config/modulesets/glucose-versionsupport.modules
+++ b/config/modulesets/glucose-versionsupport.modules
@@ -21,7 +21,6 @@
   
 
 
-  
   
   
   
diff --git a/config/modulesets/glucose.modules 
b/config/modulesets/glucose.modules
index 2a9a8ce..12c8171 100644
--- a/config/modulesets/glucose.modules
+++ b/config/modulesets/glucose.modules
@@ -21,7 +21,6 @@
   
 
 
-  
   
   
   
-- 
1.7.2.2

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

Re: [Sugar-devel] Community

[Sascha Silbe]

Excerpts from Martin Abente's message of Tue Aug 31 20:44:25 +0200 2010:

[Organising a Sugar game session, e.g. Sauerbraten]
> Why not Quake?! Quake 2 coop mode was fun ;)
AFAICT the Quake 2 game data is still proprietary, so not available to
everyone (legally). Open Arena [1] would be an Open Source alternative.
The latter (being based on Quake 3 which has a very different single
player mode than Quake 2) shares the drawback of Sauerbraten that
there's no co-op mode, though it does at least support bots (while
Sauerbraten doesn't).
Doom 2 with FreeDoom data files supports co-op mode; there's even an
activity for it [2]. I have a feeling it incorporates binary code and
won't work on most systems, but AFAIK most distros ship it so that's
not an issue. ;)

> I am not suggesting to eliminate the current process, I am just saying
> that we should define clear parameters that could help to minimize the
> current bottle necks generated by the current number of
> maintainers/reviewers and the difficulties of agreement at the coding and
> designing stages, respectively.

Do you have any concrete idea what we could do to improve or speed up
the process? What would you consider the most important blocker / what
took most of your time?

Sascha

[1] http://openarena.ws/
[2] http://wiki.laptop.org/go/Doom
--
http://sascha.silbe.org/
http://www.infra-silbe.de/


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

Re: [Sugar-devel] Patch review (was: Re: Community)

[Tomeu Vizoso]

On Thu, Sep 2, 2010 at 18:28, Sascha Silbe
 wrote:
> Excerpts from Tomeu Vizoso's message of Tue Aug 31 13:20:31 +0200 2010:
>
>> > What do you think about a model where we have some git repo that
>> > everyone can commit to after they got, say, at least two Reviewed-By
>> > (including one from a core / "long"-term developer)? The contributors
>> > would get more testing of their work (=> less bugs in the release) and
>> > the module maintainers would be able to pick resp. skip the patches they
>> > feel (un)comfortable with.
>>
>> But then we would need to resync at some point or merging would get
>> worst with time?
>
> We could rebase after each release, like (at least some of) the Linux
> folks are doing. Either on the master branch, or by creating a new
> branch for each release (like the OLPC kernel repo).

Sounds good.

>> > Another idea would be a mailing list where early versions of patches are
>> > posted and can get some (incomplete) review. This would allow
>> > contributors to get fast & easy feedback with a limited amount of time
>> > spent for the reviewers. Reviews could just point out a subset of issues;
>> > a thorough review and deciding whether it's good enough to be merged
>> > would happen like above.
>>
>> I liked how it worked in sugar-devel for a while, a separate mailing
>> list would be also ok if the reviews do disturb people or whatever is
>> the reason for having stopped doing that.
>
> To make it clear: Both the new mailing list and sugar-devel would carry
> reviews. The difference is that RFC / PoC style patches would land on
> the new mailing list, whereas those intended to get into mainline as-is
> would be on sugar-devel.
>
> This would give a clear indication about whether a patch is intended
> for mainline and also keep the "newbie" traffic off sugar-devel (IIRC
> some people have complained about the high traffic on sugar-devel).
>
> The drawback is that we might miss some feedback from people who only
> subscribe to sugar-devel but not to the new list. But then those are
> probably the same people that would have complained about the increased
> traffic. ;)
>
> An alternative would be to clearly mark patches with e.g. "RFC" in the
> subject and create mailing list topics to allow filtering out review
> related traffic. We already have "[ANNOUNCE]" and "[RELEASE]" topics
> to allow anyone to receive only important announcements. The drawback
> of this alternative is that few users notice this option and might
> unsubscribe instead of activating the topic filter.

I for one liked having patch submission and reviews in the same
channel as we discuss other development stuff. But will subscribe to
another mailing list if needed.

Regards,

Tomeu

> Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> ___
> 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] Patch review (was: Re: Community)

[Sascha Silbe]

Excerpts from Tomeu Vizoso's message of Tue Aug 31 13:20:31 +0200 2010:

> > What do you think about a model where we have some git repo that
> > everyone can commit to after they got, say, at least two Reviewed-By
> > (including one from a core / "long"-term developer)? The contributors
> > would get more testing of their work (=> less bugs in the release) and
> > the module maintainers would be able to pick resp. skip the patches they
> > feel (un)comfortable with.
> 
> But then we would need to resync at some point or merging would get
> worst with time?

We could rebase after each release, like (at least some of) the Linux
folks are doing. Either on the master branch, or by creating a new
branch for each release (like the OLPC kernel repo).

> > Another idea would be a mailing list where early versions of patches are
> > posted and can get some (incomplete) review. This would allow
> > contributors to get fast & easy feedback with a limited amount of time
> > spent for the reviewers. Reviews could just point out a subset of issues;
> > a thorough review and deciding whether it's good enough to be merged
> > would happen like above.
> 
> I liked how it worked in sugar-devel for a while, a separate mailing
> list would be also ok if the reviews do disturb people or whatever is
> the reason for having stopped doing that.

To make it clear: Both the new mailing list and sugar-devel would carry
reviews. The difference is that RFC / PoC style patches would land on
the new mailing list, whereas those intended to get into mainline as-is
would be on sugar-devel.

This would give a clear indication about whether a patch is intended
for mainline and also keep the "newbie" traffic off sugar-devel (IIRC
some people have complained about the high traffic on sugar-devel).

The drawback is that we might miss some feedback from people who only
subscribe to sugar-devel but not to the new list. But then those are
probably the same people that would have complained about the increased
traffic. ;)

An alternative would be to clearly mark patches with e.g. "RFC" in the
subject and create mailing list topics to allow filtering out review
related traffic. We already have "[ANNOUNCE]" and "[RELEASE]" topics
to allow anyone to receive only important announcements. The drawback
of this alternative is that few users notice this option and might
unsubscribe instead of activating the topic filter.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


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

Re: [Sugar-devel] screenreader for sugar

[Esteban Arias]

xo-1.0 | F11 | Dextrose version | Gnome desktop | orca 2.26.3

If I set: "run at startup"
orca run correctly.

If I excecute "orca" from Terminal, shows error:
/usr/lib/python2.6/site-packages/orca/mouse_review.py:189: Warning: invalid
uninstantiatable type `(null)' in cast to `GdkDisplayX11'
self._mouseDwellTimeout(event.detail1, event.detail2)

Displays Preferences dialog, but dont reads screen.

Regards,
Esteban Arias.

2010/9/2 Tomeu Vizoso 

> On Wed, Sep 1, 2010 at 14:51, Esteban Arias 
> wrote:
> > I install orca on xo 1.0 with gnome for f11.
> > If I config to start session with orca, runs ok. But if I execute orca
> from
> > terminal, dont run correctly:
>
> Hi Esteban,
>
> could be that your email arrived to us incomplete?
>
> Regards,
>
> Tomeu
>
> >
> >
> > 2010/9/1 pbrobin...@gmail.com 
> >>
> >> On Wed, Sep 1, 2010 at 10:24 AM, Tomeu Vizoso 
> wrote:
> >> > On Fri, Aug 20, 2010 at 14:10, Tomeu Vizoso 
> wrote:
> >> >> On Fri, Aug 20, 2010 at 14:08, Esteban Arias
> >> >>  wrote:
> >> >>> hi,
> >> >>> we can colaborate with this proyect.
> >> >>
> >> >> Excelent, have you tried already orca with Sugar? And with GNOME?
> >> >
> >> > I would say that the next step is for someone who knows how orca is
> >> > used to give it a try and file tickets for the biggest issues. Not
> >> > sure we can make much more until then.
> >>
> >> The gnome guys mentioned this the other day and there's going to be
> >> some more work done within gnome hopefully for F-14. So hopefully we
> >> should be looking better for that release.
> >>
> >> Peter
> >
> >
> >
> > --
> > Esteban Arias
> > Investigación y Desarrollo - Plan Ceibal
> > Avda. Italia 6201
> > Montevideo - Uruguay.
> > Tel.: 2601.57.73 Interno 2228
> > E-mail : ear...@plan.ceibal.edu.uy
> >
> >
>



-- 
Esteban Arias
Investigación y Desarrollo - Plan Ceibal
Avda. Italia 6201
Montevideo - Uruguay.
Tel.: 2601.57.73 Interno 2228
E-mail : ear...@plan.ceibal.edu.uy
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Autosave and Keep button

[Sascha Silbe]

Excerpts from Bert Freudenberg's message of Wed Sep 01 16:28:22 +0200 2010:

> That's one of the reasons I did not want to overload the exit button with 
> saving functionality. It simply exits (after confirming) without ever saving 
> now. To avoid confusion, it does not look like a regular stop button:
Ah, good.

> But you can't really discuss autosaving and keeping separately. They go hand 
> in hand. If an activity cannot autosave, it has to rely on the keep button, 
> right? And keeping should create a new entry - that's how it is in every 
> activity. Only autosave destructively overwrites the current entry.
Ah, so you create a new data store entry on each invocation? Then it's
actually fine to call it Keep (a copy). I thought you'd overwrite the
previous entry like before, just not automatically.

> Incidentally, on other platforms Etoys does versioning itself - every project 
> saved has a version number embedded in the file name that is not visible in 
> the UI. In the file-open dialog, all but the highest numbered versions are 
> hidden.

A (really) bad hack would be to change the timestamp of the previous entry
to something years ago, so it usually wouldn't show up.
But instead we should really work on getting version support into Sugar
mainline.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


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

Re: [Sugar-devel] screenreader for sugar

[Tomeu Vizoso]

On Wed, Sep 1, 2010 at 14:51, Esteban Arias  wrote:
> I install orca on xo 1.0 with gnome for f11.
> If I config to start session with orca, runs ok. But if I execute orca from
> terminal, dont run correctly:

Hi Esteban,

could be that your email arrived to us incomplete?

Regards,

Tomeu

>
>
> 2010/9/1 pbrobin...@gmail.com 
>>
>> On Wed, Sep 1, 2010 at 10:24 AM, Tomeu Vizoso  wrote:
>> > On Fri, Aug 20, 2010 at 14:10, Tomeu Vizoso  wrote:
>> >> On Fri, Aug 20, 2010 at 14:08, Esteban Arias
>> >>  wrote:
>> >>> hi,
>> >>> we can colaborate with this proyect.
>> >>
>> >> Excelent, have you tried already orca with Sugar? And with GNOME?
>> >
>> > I would say that the next step is for someone who knows how orca is
>> > used to give it a try and file tickets for the biggest issues. Not
>> > sure we can make much more until then.
>>
>> The gnome guys mentioned this the other day and there's going to be
>> some more work done within gnome hopefully for F-14. So hopefully we
>> should be looking better for that release.
>>
>> Peter
>
>
>
> --
>     Esteban Arias
>     Investigación y Desarrollo - Plan Ceibal
>     Avda. Italia 6201
>     Montevideo - Uruguay.
>     Tel.: 2601.57.73 Interno 2228
>     E-mail : ear...@plan.ceibal.edu.uy
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] #2230 UNSP: Fototoon 3 does not show controls when speech bubble first selected

[Gonzalo Odiard]

Yes. I will.

Gonzalo

On Thu, Sep 2, 2010 at 7:27 AM, Sugar Labs Bugs <
bugtracker-nore...@sugarlabs.org> wrote:

> #2230: Fototoon 3 does not show controls when speech bubble first selected
>
> --+-
>Reporter:  carrott|  Owner:  godiard
>Type:  defect | Status:  assigned
>Priority:  Unspecified by Maintainer  |  Milestone:  Unspecified by
> Release Team
>   Component:  ActivityTeam   |Version:  0.88.x
>Severity:  Minor  |   Keywords:  dextrose
> Distribution:  Fedora |   Status_field:  Unconfirmed
>
> --+-
> Changes (by bernie):
>
>  * owner:  garycmartin => godiard
>
>
> Comment:
>
>  Gonzalo, could you give a look at this bug?
>
> --
> Ticket URL: 
> Sugar Labs 
> Sugar Labs bug tracking system
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] Stability stuff

[Martin Abente]

Weird, I really tried to trigger it on our last Dextrose build and never
happened.

The whole idea of killing activities is a little bit controversial I
think, you have to assume to many things about activities, so far just a
few activities in sugar uses all the proper mechanisms, I am afraid that in
most of the cases kids would just loose their current work.

What about... If the system load is already close to a "critical" point,
SUGAR could just stop new activities from being executed with a proper
warning, and suggestions.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [olpc-nz] Twi translation

[David Farning]

I have forwarded this to sugar-devel.  Often I have seen sysamindu
handle these requests on IRC.  But I believe he has returned to
school.

david

On Thu, Sep 2, 2010 at 4:54 AM, Tabitha Roder  wrote:
> On 31 August 2010 09:10, Brenda Wallace  wrote:
>>
>> My colleague, Charlie, has vounteered to do Twi translations of sugar
>> text. Twi is the language of Ghana.
>> Anyone on this list set up translation before? Can you point on the
>> way to get an interface infront of Charlie so he can go for it?
>>
>>
>
> I got Tongan, Maori and Samoan started. Best thing to do is submit request
> to http://bugs.sugarlabs.org/ that says "please create Twi language and add
> terminology project and glucose project".
>
> We suggest the terminology project (these are like keywords that give you a
> start point for all the other projects) and glucose project (the main file
> for the majority of words found in the Sugar interface) before tackling the
> others. The translation team should respond pretty quick.
>
> Charlie will need access to Sugar (on a Stick is fine) to see the words in
> context while doing the translation.
>
> Tabitha
>
> ___
> olpc-nz mailing list
> olpc...@lists.laptop.org
> http://lists.laptop.org/listinfo/olpc-nz
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] how many maintainers? (was Re: Bug tracking Vs Patch review)

[David Farning]

On Thu, Sep 2, 2010 at 2:50 AM, Tomeu Vizoso  wrote:
> On Wed, Sep 1, 2010 at 16:18, Bernie Innocenti  wrote:
>> El Tue, 31-08-2010 a las 10:33 +0200, Tomeu Vizoso escribió:
>>>
>>> And we have how many full-time maintainers?
>>
>> We have several, no? You, erikos, alsroot... plus several part-time
>> ones.
>
> Collabora is sponsoring me between 1 and 2 weekly days to do anything
> related to Sugar apart from the collaboration work, this includes
> maintenance but also quite a bit of other stuff (such as reading and
> replying emails).
>
> I'm pretty sure OLPC is not contracting Simon just for maintenance work.
>
> Is Aleksey hired full-time for maintenance work? What about Anish?

Activity Central has hired Aleksey to mentor new developers. I think
this requires about 3 hour per day.  This Leaving him the rest of his
time to what every he wants -- Oinstall:)

Activity Central and ParaguayEduca have jointly hired Anish to work
onsite at ParaguaryEduca to improve the flow between their deployment
and upstream Sugar and OLPC.

david

> Regards,
>
> Tomeu
> ___
> 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] Autosave and Keep button

[Bert Freudenberg]

On 02.09.2010, at 09:27, Tomeu Vizoso wrote:

> On Wed, Sep 1, 2010 at 16:28, Bert Freudenberg  wrote:
>> On 01.09.2010, at 14:01, Sascha Silbe wrote:
>> 
>>> Excerpts from Gary Martin's message of Tue Aug 31 20:07:12 +0200 2010:
>>> 
 My first gut reaction (not having seen it yet) is that the Keep button is 
 a real problem generally (and causes confusion and misunderstanding in 
 Sugar). Habitually training kids to click that icon each time before 
 exiting will, for all other activities, generate many confusing duplicate 
 Journal entries over time and make matters even worse.
>>> 
>>> +1
>>> 
 For the Etoys case, as a workaround for not knowing your clean/dirty 
 state, I think having the regular Stop UI button that when clicked 
 _always_ displayed some sort of "Do you want to Keep the changes to this 
 project in the Journal?" Keep/Don't Keep dialogue.
>>> 
>>> Having the Stop button ask which version (the one in the Journal or the
>>> one currently loaded) to destroy is a bad idea, but unsolvable without
>>> version support.
>>> Please avoid the Keep terminology in this context; it's only going to
>>> confuse users even more.
>>> 
>>> Sascha
>> 
>> That's one of the reasons I did not want to overload the exit button with 
>> saving functionality. It simply exits (after confirming) without ever saving 
>> now. To avoid confusion, it does not look like a regular stop button:
>> 
>> 
>> 
>> But you can't really discuss autosaving and keeping separately. They go hand 
>> in hand. If an activity cannot autosave, it has to rely on the keep button, 
>> right? And keeping should create a new entry - that's how it is in every 
>> activity. Only autosave destructively overwrites the current entry.
>> 
>> I am warming up to Gary's suggestion though because it's the only way to 
>> avoid needless Journal entries, unless we introduce a "save/save-as" 
>> distinction.
>> 
>> Incidentally, on other platforms Etoys does versioning itself - every 
>> project saved has a version number embedded in the file name that is not 
>> visible in the UI. In the file-open dialog, all but the highest numbered 
>> versions are hidden. Now maybe if the Journal had a "hide" attribute for an 
>> entry, the Journal would look less cluttered. Also, when running out of 
>> space the hidden entries could be used to free up space. Wait, that's 
>> re-inventing the trash can ... but maybe not a bad idea after all.
> 
> The (some?) plans for versioning in the journal called for hiding the
> less relevants revisions in the main view and only displaying them in
> the detailed view.
> 
> Regards,
> 
> Tomeu

Yes, I know. However, "real" versioning seems to be far too complicated to 
actually get implemented and adopted. It might be too large a step.

It would be (IMHO) much simpler if updating a Journal entry would just make a 
"hidden" copy with the old contents and metadata first. 

This "poor man's versioning" would alleviate the destructive nature of 
auto-save. It *would* be possible to access "overwritten" versions if necessary.

OTOH that's tangential to the Etoys problem, which would not be solved even by 
a real versioning scheme. In Etoys, auto-save is rarely what the user needs. 
Maybe if the explicitly kept versions were preferred over the auto-saved ones 
... But then it's hard to tell. 

Hmm, remind me again why resume-by-default from the home view was a good idea. 
I know I supported it at the time we discussed it. It works well for e.g. 
Terminal. But for activities like Etoys it gets in the way. How about we allow 
activities to disable it in activity.info?

- Bert -


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

[Sugar-devel] [ANNOUNCE] Sucrose 0.89.5 Development (Beta) Release

[Simon Schampijer]

Dear Sugar Community,

this is our development release number 5 in the 0.90 development cycle 
[1]! This is our Beta release! We would like to invite you for testing 
now. The plan is to have a Soas build with the latest 0.90 Sugar 
packages available by the end of the week. We will send another 
announcement when it is ready for download.

We now reached String Freeze [2], no string changes may be made without 
confirmation from the localization team and notification to the release 
team! We encourage translators to translate the new strings that has 
been introduced by the various new Features.

Furthermore Tomeu Vizoso made great progress in fixing integration bugs 
introduced by the Remove Presence Service Feature [3].

The Etoys team reports that the first beta release of Etoys 4.1 is now 
available. The biggest change is that stopping the Etoys activity will 
no longer save to the Journal. To save, you will have to press the keep 
button. The octagonal stop button is replaced by a circular exit button 
to indicate the new behavior. It puts up a warning before actually 
quitting. More about the rationale for this change can be found at [4].

Full release notes can be found at [5].

Thanks everyone for your great contributions!

In behalf of the sugar community,
 Your Release Team

[1] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule
[2] http://wiki.sugarlabs.org/go/Development_Team/Release#String_Freeze
[3] http://wiki.sugarlabs.org/go/Features/Remove_Presence_Service
[4] http://lists.sugarlabs.org/archive/sugar-devel/2010-August/026398.html
[5] http://wiki.sugarlabs.org/go/0.90/0.89.5_Notes



== Compatibility ==
There are no known compatibility issues, as of today.

== Update to this version ==
Please use the instructions for your distribution (SoaS, Fedora, Ubuntu, 
Debian etc) of choice to upgrade to this release. Note that it may take 
a while until the release is packaged for each distribution.

== Glucose modules==

===Updated===
* 
http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.89.7.tar.bz2
* 
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.89.5.tar.bz2
* 
http://download.sugarlabs.org/sources/sucrose/glucose/etoys/etoys-4.1.2384.tar.gz
 


== Glucose news ==
=== sugar ===
* AP: signal strength update not separate from state change {{Bug|2246}} 
(Simon Schampijer)
* Listen to changes to the nick and jabber server settings and update MC 
appropriately (Tomeu Vizoso)
* Journal: Alert if an error occurs when copying to devices in the 
detail view {{Bug|1842}} (Simon Schampijer)
* Sugar GConf settings breaks mouse buttons behavior in gnome session 
{{Bug|1544}} (Aleksey Lim)

=== sugar-toolkit ===
* sugar.presence: Remove dead code and make clear which methonds are 
deprecated (Tomeu Vizoso)
* Read the public and private keys lazily (Tomeu Vizoso)
* Use Account.ConnectionStatus instead of Account.Connection.Status 
(Tomeu Vizoso)

=== Etoys ===
* no save on stop under Sugar, must use keep button (enable 
sugarAutoSave to revert to old behavior)
* easier to make flap (see supplies)
* GSoC addition: scriptable speech bubbles
* translatability of Text object must be enabled explicitly
* minor fixes
* updated translations from Pootle
* added languages zh_CN, ca, sk, pap, pl, km, en_GB, ar_SY
* revised Italian, Portuguese, and German QuickGuides

== What is new for packagers ==
New API has been added to telepathy-gabble and telepathy-salut to 
support the work on the collaboration framework, which results in 
needing 0.9.16 for tp-gabble and 0.3.13 for tp-salut.

One of the goals of the collaboration refactoring was dropping 
functionality in sugar that has been implemented in 
[http://telepathy.freedesktop.org/wiki/Mission%20Control 
telepathy-mission-control], so Sugar now depends on tp-mission-control 
5.4.3.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Dextrose] Stability stuff

[Bernie Innocenti]

El Tue, 31-08-2010 a las 12:00 -0400, Martin Abente escribió:
> Hey guys, 
> 
> I have been testing our last dextrose build for the XO 1, and comparing it
> to the previous os179py (Sugar 0.84) version. I have noticed that the
> kernel included in the os179os provides a mechanism for killing activities
> when the laptop runs out of memory.

This is the kernel out-of-memory killer. It's been in the Linux kernel
since 2.4.x, so all versions of the XO software include it.

The OOM killer makes its guess using heuristics. Sometimes, it could
kill the wrong process, leaving the machine in an unusable state.
Killing processes should be seen as a last-resort action, to recover
from a situation that should never happen. Unfortunately, Sugar does not
have any mechanism to gracefully quit activities when memory is tight. 

Technically, this is not a bug in Sugar or in Dextrose. OOM killing is
the normal behavior of Linux even on servers. It's just that it's too
easy to trigger on the XO.

If you grep the OLPC and Sugar development mailing lists, you'll find
many threads in which this topic was discussed and solutions were
proposed. One such threads happened recently in conjunction with the
discussion of Anish's CPU & Memory meter.

I liked the solution that was proposed last: when memory gets tight,
Sugar simply asks the least recently used activity to quit (and thus
save to the journal). Optionally, we could put on a notification to let
the user know what happened (after the fact).


> I have tried to trigger this mechanism on our last dextrose build, but
> with no results. Is it possible that our last kernel does not include this 
> mechanism? And in that case is there any reason for not including it?

No, all kernels include it. There are a bunch of tunables
in /proc/sys/vm to make the oom killer behave differently. The most
important one is "swappiness", which seems to be set a little bit too
high on the current OLPC kernels (all of them, not just Dextrose).

Note that we're using the very same kernel that OLPC uses on os852, so
bugs should be shared.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

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

Re: [Sugar-devel] how many maintainers? (was Re: Bug tracking Vs Patch review)

[Simon Schampijer]

On 09/02/2010 09:50 AM, Tomeu Vizoso wrote:
> On Wed, Sep 1, 2010 at 16:18, Bernie Innocenti  wrote:
>> El Tue, 31-08-2010 a las 10:33 +0200, Tomeu Vizoso escribió:
>>>
>>> And we have how many full-time maintainers?
>>
>> We have several, no? You, erikos, alsroot... plus several part-time
>> ones.

Yes, I can spend a bit of my working time on maintenance. Though I do as 
well release management. And of course I can not do upstream work all day :)

And until recently I did maintenance in my spare time. It is probably 
fair to say that until recently Tomeu did most of the maintenance work 
of the development branch.

So yes, having more maintainers would speed up that part of our work.

Regards,
Simon

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

[Sugar-devel] sugar broken in F14? (was Re: Bug tracking Vs Patch review)

[Tomeu Vizoso]

On Wed, Sep 1, 2010 at 16:18, Bernie Innocenti  wrote:
> El Tue, 31-08-2010 a las 10:33 +0200, Tomeu Vizoso escribió:
>
>> > Regardless, we proceeded to
>> > release 0.89.5 tarballs that downstreams promptly turned into broken
>> > packages (tested on Fedora).
>>
>> You clearly had different results than me when testing on F14, have
>> you filed bugs or reported them in some place?
>
> What distro did you use? It also fails on Ubuntu and Fedora 13 according
> to other people on #sugar. Did you really hear about this for the first
> time for me?

I'm testing daily the Sugar 0.90 packages that Peter (big thanks!) is
doing on F14 and the tarballs that you see I'm making are intended to
fix issues I find there. I'm still updating, but as of yesterday Sugar
was starting correctly and I couldn't find any major issues.

I alone won't find all the issues so if you (and others) can file the
bugs you find, I will be able to fix them faster.

Thanks,

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

[Sugar-devel] jhbuild breakage (was Re: Bug tracking Vs Patch review)

[Tomeu Vizoso]

On Wed, Sep 1, 2010 at 16:18, Bernie Innocenti  wrote:
> El Tue, 31-08-2010 a las 10:33 +0200, Tomeu Vizoso escribió:
>>
>> Patches were promptly made available in the mailing list and some have
>> already been accepted by Sascha into jhbuild.
>
> Still doesn't work here, neither with jhbuild nor with Fedora packages.
> It's not a mere dependency issue:
>
>  http://bugs.sugarlabs.org/ticket/2269
>  http://bugs.sugarlabs.org/ticket/2270

Are you *sure* you applied the patch in http://bugs.sugarlabs.org/ticket/2228 ?

I have just went through a clean checkout and build of jhbuild on F13
and it just worked (the patch there has bitrotten a bit but the merge
is trivial). If you indeed applied the patch and it's something
system-specific we'll need more information than what is available on
the tickets right now.

If there are other people having trouble with jhbuild right now would
be good if they shared their experiences in this thread.

Thanks,

Tomeu

> A few days ago I was also seeing another error in the logs about a
> missing changed-activity signal, but it seems to have disappeared now.
>
>
>> > Regardless, we proceeded to
>> > release 0.89.5 tarballs that downstreams promptly turned into broken
>> > packages (tested on Fedora).
>>
>> You clearly had different results than me when testing on F14, have
>> you filed bugs or reported them in some place?
>
> What distro did you use? It also fails on Ubuntu and Fedora 13 according
> to other people on #sugar. Did you really hear about this for the first
> time for me?
>
>
>> By the way, this is called integration testing and it happens every
>> cycle in GNOME's jhbuild and again when stuff gets packaged at first
>> in Fedora.
>
> We're not talking about a minor integration glitch. It's broken on 3
> distros (minimum).
>
>
>> The problems found during the integration phase are due to the
>> unexpected effects of putting together for the first time specific
>> versions of hundreds of different dependencies built with specific
>> sets of build options (such as the gnome-keyring issue with
>> mission-control). How did you expected to catch those by reading Sugar
>> patches?
>
> Not by reading patches, but by having the maintainer test that at least
> jhbuild still runs before pushing, or at least before releasing
> tarballs.
>
> But I'm assuming that Sugar is currently broken for everyone, which does
> not seem to be the case at least for you.
>
>
>> > We seem to be missing the equivalent of a "product manager"... someone
>> > who cares for the product as a whole. In a different occasion, Walter
>> > noted the need for an "architect", but in a project like ours these are
>> > very much the same thing, just with an emphasis on the present or on the
>> > future.
>>
>> It would help if you described that role in some details, otherwise
>> can mean too many different things.
>
> This is more or less what I'm thinking of:
>
>  http://en.wikipedia.org/wiki/Product_manager
>
>
> This is common business practice. If you prefer the agile software
> development terminology, we need a "Product Owner" for Sugar.
>
> Walter some time ago called for an Architect, which is something close,
> but with a focus on technical aspects of the product and long-term
> evolution of the codebase.
>
>
>> > We merged a total of 355 patches in sugar over the last 365 months.
>> > Exactly one patch per day. Over the same period, Linus merged 100 times
>> > this number of patches,
>>
>> Looks like you are onto something big here. After you fix Sugar you
>> can go fix GNOME and the rest of FOSS projects, then with 100 times
>> more productivity Microsoft, Apple and Google will disappear in a puff
>> of smoke.
>>
>> > meaning that maintaining Sugar should be
>> > feasible even as a part-time job.
>>
>> And we have how many full-time maintainers?
>
> We have several, no? You, erikos, alsroot... plus several part-time
> ones.
>
> So complaining that we don't have enough maintainers for merging 350
> patches per year is clearly missing the point. The problem we have is
> one of organization, not one one of resources.
>
> The number of new features and bugfixes in Dextrose proves that there
> are abundant resources for Sugar development. We're just blocking them
> from contributing effectively because the processes we have in place
> don't work well.
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] how many maintainers? (was Re: Bug tracking Vs Patch review)

[Tomeu Vizoso]

On Wed, Sep 1, 2010 at 16:18, Bernie Innocenti  wrote:
> El Tue, 31-08-2010 a las 10:33 +0200, Tomeu Vizoso escribió:
>>
>> And we have how many full-time maintainers?
>
> We have several, no? You, erikos, alsroot... plus several part-time
> ones.

Collabora is sponsoring me between 1 and 2 weekly days to do anything
related to Sugar apart from the collaboration work, this includes
maintenance but also quite a bit of other stuff (such as reading and
replying emails).

I'm pretty sure OLPC is not contracting Simon just for maintenance work.

Is Aleksey hired full-time for maintenance work? What about Anish?

Regards,

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

Re: [Sugar-devel] Autosave and Keep button

[Tomeu Vizoso]

On Wed, Sep 1, 2010 at 16:28, Bert Freudenberg  wrote:
> On 01.09.2010, at 14:01, Sascha Silbe wrote:
>
>> Excerpts from Gary Martin's message of Tue Aug 31 20:07:12 +0200 2010:
>>
>>> My first gut reaction (not having seen it yet) is that the Keep button is a 
>>> real problem generally (and causes confusion and misunderstanding in 
>>> Sugar). Habitually training kids to click that icon each time before 
>>> exiting will, for all other activities, generate many confusing duplicate 
>>> Journal entries over time and make matters even worse.
>>
>> +1
>>
>>> For the Etoys case, as a workaround for not knowing your clean/dirty state, 
>>> I think having the regular Stop UI button that when clicked _always_ 
>>> displayed some sort of "Do you want to Keep the changes to this project in 
>>> the Journal?" Keep/Don't Keep dialogue.
>>
>> Having the Stop button ask which version (the one in the Journal or the
>> one currently loaded) to destroy is a bad idea, but unsolvable without
>> version support.
>> Please avoid the Keep terminology in this context; it's only going to
>> confuse users even more.
>>
>> Sascha
>
> That's one of the reasons I did not want to overload the exit button with 
> saving functionality. It simply exits (after confirming) without ever saving 
> now. To avoid confusion, it does not look like a regular stop button:
>
>
>
> But you can't really discuss autosaving and keeping separately. They go hand 
> in hand. If an activity cannot autosave, it has to rely on the keep button, 
> right? And keeping should create a new entry - that's how it is in every 
> activity. Only autosave destructively overwrites the current entry.
>
> I am warming up to Gary's suggestion though because it's the only way to 
> avoid needless Journal entries, unless we introduce a "save/save-as" 
> distinction.
>
> Incidentally, on other platforms Etoys does versioning itself - every project 
> saved has a version number embedded in the file name that is not visible in 
> the UI. In the file-open dialog, all but the highest numbered versions are 
> hidden. Now maybe if the Journal had a "hide" attribute for an entry, the 
> Journal would look less cluttered. Also, when running out of space the hidden 
> entries could be used to free up space. Wait, that's re-inventing the trash 
> can ... but maybe not a bad idea after all.

The (some?) plans for versioning in the journal called for hiding the
less relevants revisions in the main view and only displaying them in
the detailed view.

Regards,

Tomeu

> - Bert -
>
>
>
> ___
> 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