Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-09 Thread J.M. Maurer
On Tue, 2009-11-03 at 15:19 +0100, Martin Langhoff wrote:
 On Tue, Nov 3, 2009 at 2:41 PM, Gary C Martin g...@garycmartin.com wrote:
  Other activities that support some form of collaboration like Chat, Browse,
  Etoys, TurtleArt, Arithmetic, Maze, Pippy, etc, etc, don't care who started
  the activity first, or who goes away.
 
 Are you positive about this? I don't meant to troll -- but I am seeing
 issues (with Chat for example) where if the leader goes, 3rd parties
 cannot join anymore.

I tried to make rejoining work with Write, but ran into bugs into both
the PS and Telepathy Gabble.

For the PS bug, tomeu has a patch but it never went in.

The Telepathy gabble bug prevented you from rejoining an existing tube,
so it could never have worked for any application (including chat).

The Telepathy gabble bug is fixed in F11 and F12, but I did not test if
Write rejoining now works (it could still have bugs, simply because I
could never test it).

Cheers,
  Marc

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-08 Thread Tomeu Vizoso
On Sat, Nov 7, 2009 at 17:40, David Van Assche dvanass...@gmail.com wrote:
 Hi,
    So I was looking over the code with some of the #telepathy guys who are
 also under the impression that sugar.presence code could be causing many of
 the collab problems. Main issue is redundancy of code... a lot of what is
 happening in sugar.presence already happens in telepathy (actually there are
 even comments in sugar.presence code stating this) but until we know to what
 level activities are using sugar.presence, we can't really do anything...
 since activities would break, I guess we'd need to know what in the
 sugar.presence modules is being really actively used to migrate to MC 5...
 and give a warning or something, or keep some kind of sym links to the old
 functions... I dunno, kinda above my level of expertise...

Yes, info about presence is duplicated in several places. Any bugs at
each layer can cause the unreliability we see.

Regards,

Tomeu

 regards,
 David van Assche

 On Fri, Nov 6, 2009 at 2:02 PM, Tomeu Vizoso to...@sugarlabs.org wrote:

 On Wed, Nov 4, 2009 at 13:16, Benjamin M. Schwartz
 bmsch...@fas.harvard.edu wrote:
  Martin Langhoff wrote:
  On Tue, Nov 3, 2009 at 9:54 PM, David Van Assche dvanass...@gmail.com
  wrote:
  moving to mission control 5 and letting go of the admittedly
  antiquated sugar presence now
  ...
  If you play with a major component replacement
 
   - test it for scalability  stability over wifi before doing a lot of
  integration work
 
  It's worth noting that moving from the Sugar Presence Service to Mission
  Control 5 would not alter our network protocols.  This is purely a
  change
  in how the client software is organized.  Neither regression nor
  improvement in wireless network performance should occur.

 Was about to say this, the work means making sugar activities' code
 more similar to GNOME apps, while also removing a daemon. This could
 have some effect on how the network is used, but chances are it won't.

 As a first step in removing the PS, I think we should try to implement
 the python presence API with MC5 instead of PS. Then we can either
 drop the PS or make it a compatibility shim with MC5 while activities
 such as eToys make the move.

 We can also take the chance to develop a better API if there's need for
 it.

 But in any case, we need to do some exploration now before we can
 discuss it in detail.

 Regards,

 Tomeu

 --
 «Sugar Labs is anyone who participates in improving and using Sugar.
 What Sugar Labs does is determined by the participants.» - David
 Farning
 ___
 Sugar-devel mailing list
 sugar-de...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel



 --

 Marie von Ebner-Eschenbach  - Even a stopped clock is right twice a day.



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-07 Thread David Van Assche
Hi,
   So I was looking over the code with some of the #telepathy guys who are
also under the impression that sugar.presence code could be causing many of
the collab problems. Main issue is redundancy of code... a lot of what is
happening in sugar.presence already happens in telepathy (actually there are
even comments in sugar.presence code stating this) but until we know to what
level activities are using sugar.presence, we can't really do anything...
since activities would break, I guess we'd need to know what in the
sugar.presence modules is being really actively used to migrate to MC 5...
and give a warning or something, or keep some kind of sym links to the old
functions... I dunno, kinda above my level of expertise...

regards,
David van Assche

On Fri, Nov 6, 2009 at 2:02 PM, Tomeu Vizoso to...@sugarlabs.org wrote:

 On Wed, Nov 4, 2009 at 13:16, Benjamin M. Schwartz
 bmsch...@fas.harvard.edu wrote:
  Martin Langhoff wrote:
  On Tue, Nov 3, 2009 at 9:54 PM, David Van Assche dvanass...@gmail.com
 wrote:
  moving to mission control 5 and letting go of the admittedly
  antiquated sugar presence now
  ...
  If you play with a major component replacement
 
   - test it for scalability  stability over wifi before doing a lot of
  integration work
 
  It's worth noting that moving from the Sugar Presence Service to Mission
  Control 5 would not alter our network protocols.  This is purely a change
  in how the client software is organized.  Neither regression nor
  improvement in wireless network performance should occur.

 Was about to say this, the work means making sugar activities' code
 more similar to GNOME apps, while also removing a daemon. This could
 have some effect on how the network is used, but chances are it won't.

 As a first step in removing the PS, I think we should try to implement
 the python presence API with MC5 instead of PS. Then we can either
 drop the PS or make it a compatibility shim with MC5 while activities
 such as eToys make the move.

 We can also take the chance to develop a better API if there's need for it.

 But in any case, we need to do some exploration now before we can
 discuss it in detail.

 Regards,

 Tomeu

 --
 «Sugar Labs is anyone who participates in improving and using Sugar.
 What Sugar Labs does is determined by the participants.» - David
 Farning
 ___
 Sugar-devel mailing list
 sugar-de...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel




-- 

Marie von 
Ebner-Eschenbachhttp://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html
- Even a stopped clock is right twice a day.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-04 Thread Martin Langhoff
On Tue, Nov 3, 2009 at 9:54 PM, David Van Assche dvanass...@gmail.com wrote:
 moving to mission control 5 and letting go of the admittedly
 antiquated sugar presence now

In planning future work in rpesence and collab stuff, I have a small,
humble suggestion.

Figuring out if a presence service / collab infra works and scales
properly on both wired and wireless networks is hard. Very hard. We've
been gotten it wrong several times by looking at the theory (instead
of hard-nosed testing).

Right now we have something that -- while less than ideal -- at least
works for a number of scenarios.

If you play with a major component replacement

 - test it for scalability  stability over wifi before doing a lot of
integration work

 - do the integr work on a branch

 - test that the integrated thing works stable and scalable

Of course that's ideal world stuff. However, the heart of the matter
is: approach mission control tentatively... and at least _some_
significant testing needs to happen before it's merged...

We've gotten this wrong a few times -- I am not keen on repeating the
adventures... :-/



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-04 Thread David Van Assche
Well, at least on Gnome, Mission Control not only works well, but its
far more stable and does what its supposed to. Its been very heavily
tested by Nokia (Maemo), Collabra, Google, openmoko and other heavy
hitters. I don't really agree that we have something that works with
sugar presence. In the majority of cases, where  we've had testing
sessions, though admittedly, with badly callibrated xmpp servers, I
would go so far as to say that it was attrocious in terms of
performance and stability. Once connected, collaboration worked great,
but the stuff that happens before that, which is what sugar presence
is supposed to be taking care of does not work well at all. If you
take a look at telepathy-inspector and the advancements in telepathy
itself, of which mission control 5 is one of the major overhauls, its
massive improvement over the passed. And one of the main issues was
that sugar presence used its own bindings, blind sighting a lot of
what telepathy is doing, which is why currently it simply doesn't
work. Without a xmpp server, you'll have a field day getting any kind
of collaboration to work, and even with a really carefully setup
ejabbberd server full of optimisations, I at least, have not been able
to get the presence part to reliably do the same thing every time.
Some times people show up, sometimes they dont sometimes 10 minutes
later, sometimes with totally weird settings and names Its quite
clear to me that what may have worked ok in 0.82, now does not. And to
me that makes total sense, if u look at the timeline, the code, the
blueprints, and most importantly, the actualised telepathy dbus
bindings (The presence part has changed completely and looks nothing
like it did when 0.82 and earlier were coded.)

But dont take my word for it, take a look here and you'll see what I
mean: http://people.collabora.co.uk/~danni/telepathy-book/chapter.accounts.html

kind regards,
David Van Assche

On Wed, Nov 4, 2009 at 10:38 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
 On Tue, Nov 3, 2009 at 9:54 PM, David Van Assche dvanass...@gmail.com wrote:
 moving to mission control 5 and letting go of the admittedly
 antiquated sugar presence now

 In planning future work in rpesence and collab stuff, I have a small,
 humble suggestion.

 Figuring out if a presence service / collab infra works and scales
 properly on both wired and wireless networks is hard. Very hard. We've
 been gotten it wrong several times by looking at the theory (instead
 of hard-nosed testing).

 Right now we have something that -- while less than ideal -- at least
 works for a number of scenarios.

 If you play with a major component replacement

  - test it for scalability  stability over wifi before doing a lot of
 integration work

  - do the integr work on a branch

  - test that the integrated thing works stable and scalable

 Of course that's ideal world stuff. However, the heart of the matter
 is: approach mission control tentatively... and at least _some_
 significant testing needs to happen before it's merged...

 We've gotten this wrong a few times -- I am not keen on repeating the
 adventures... :-/



 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- School Server Architect
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff




-- 

Stephen Leacock  - I detest life-insurance agents: they always argue
that I shall some day die, which is not so. -
http://www.brainyquote.com/quotes/authors/s/stephen_leacock.html
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-04 Thread David Van Assche
Don't get me wrong though, I agree thoroughly that we should really
test it and make sure it plays as advertised But I think its gonna
be easier to do that than test/scale/stabalise what we currently have.

David

On Wed, Nov 4, 2009 at 11:06 AM, David Van Assche dvanass...@gmail.com wrote:
 Well, at least on Gnome, Mission Control not only works well, but its
 far more stable and does what its supposed to. Its been very heavily
 tested by Nokia (Maemo), Collabra, Google, openmoko and other heavy
 hitters. I don't really agree that we have something that works with
 sugar presence. In the majority of cases, where  we've had testing
 sessions, though admittedly, with badly callibrated xmpp servers, I
 would go so far as to say that it was attrocious in terms of
 performance and stability. Once connected, collaboration worked great,
 but the stuff that happens before that, which is what sugar presence
 is supposed to be taking care of does not work well at all. If you
 take a look at telepathy-inspector and the advancements in telepathy
 itself, of which mission control 5 is one of the major overhauls, its
 massive improvement over the passed. And one of the main issues was
 that sugar presence used its own bindings, blind sighting a lot of
 what telepathy is doing, which is why currently it simply doesn't
 work. Without a xmpp server, you'll have a field day getting any kind
 of collaboration to work, and even with a really carefully setup
 ejabbberd server full of optimisations, I at least, have not been able
 to get the presence part to reliably do the same thing every time.
 Some times people show up, sometimes they dont sometimes 10 minutes
 later, sometimes with totally weird settings and names Its quite
 clear to me that what may have worked ok in 0.82, now does not. And to
 me that makes total sense, if u look at the timeline, the code, the
 blueprints, and most importantly, the actualised telepathy dbus
 bindings (The presence part has changed completely and looks nothing
 like it did when 0.82 and earlier were coded.)

 But dont take my word for it, take a look here and you'll see what I
 mean: 
 http://people.collabora.co.uk/~danni/telepathy-book/chapter.accounts.html

 kind regards,
 David Van Assche

 On Wed, Nov 4, 2009 at 10:38 AM, Martin Langhoff
 martin.langh...@gmail.com wrote:
 On Tue, Nov 3, 2009 at 9:54 PM, David Van Assche dvanass...@gmail.com 
 wrote:
 moving to mission control 5 and letting go of the admittedly
 antiquated sugar presence now

 In planning future work in rpesence and collab stuff, I have a small,
 humble suggestion.

 Figuring out if a presence service / collab infra works and scales
 properly on both wired and wireless networks is hard. Very hard. We've
 been gotten it wrong several times by looking at the theory (instead
 of hard-nosed testing).

 Right now we have something that -- while less than ideal -- at least
 works for a number of scenarios.

 If you play with a major component replacement

  - test it for scalability  stability over wifi before doing a lot of
 integration work

  - do the integr work on a branch

  - test that the integrated thing works stable and scalable

 Of course that's ideal world stuff. However, the heart of the matter
 is: approach mission control tentatively... and at least _some_
 significant testing needs to happen before it's merged...

 We've gotten this wrong a few times -- I am not keen on repeating the
 adventures... :-/



 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- School Server Architect
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff




 --

 Stephen Leacock  - I detest life-insurance agents: they always argue
 that I shall some day die, which is not so. -
 http://www.brainyquote.com/quotes/authors/s/stephen_leacock.html




-- 

Marie von Ebner-Eschenbach  - Even a stopped clock is right twice a
day. - 
http://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-03 Thread Walter Bender
We can set a new baseline for Sugar, but the behavior you are
describing is largely one determined by the activities themselves.
This was the subject of Ben Schwartz's GSoC project. He made great
headway, but there remains the problem that most activities are not
utilizing his approach. Something else to discuss in Bolzano. (I am
thinking we should have a day dedicated to bringing activities up to
0.86 standards.)

-walter

On Tue, Nov 3, 2009 at 6:32 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
 We have had major issues for a while with any collaboration where the
 leader (the node that created the collaboration instance) goes away.
 In Sugar 0.82 all sorts of confusion ensues, with the exact symptoms
 varying between the programs used.

 Is this expected to be fixed in 0.84 or 0.86? In looking at
 interaction with the XS, I am testing various aspects of
 collaboration... I don't want to pester people with things that are
 known not to work (and to require major engineering!).

 cheers,


 m
 --
  martin.langh...@gmail.com
  mar...@laptop.org -- School Server Architect
  - ask interesting questions
  - don't get distracted with shiny stuff  - working code first
  - http://wiki.laptop.org/go/User:Martinlanghoff
 ___
 Sugar-devel mailing list
 sugar-de...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel




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


Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-03 Thread Martin Langhoff
On Tue, Nov 3, 2009 at 2:11 PM, Walter Bender walter.ben...@gmail.com wrote:
 We can set a new baseline for Sugar, but the behavior you are
 describing is largely one determined by the activities themselves.

I understood it was a limitation in Telepathy itself, or in how Sugar
uses it (hence the need to address it in Sugar or in the Sugar
Stack.

Either way, I read in your reply that I shouldn't have hopes for it.
Understood - thanks!


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-03 Thread Gary C Martin
Hi Martin,

On 3 Nov 2009, at 13:18, Martin Langhoff wrote:

 On Tue, Nov 3, 2009 at 2:11 PM, Walter Bender  
 walter.ben...@gmail.com wrote:
 We can set a new baseline for Sugar, but the behavior you are
 describing is largely one determined by the activities themselves.

 I understood it was a limitation in Telepathy itself, or in how Sugar
 uses it (hence the need to address it in Sugar or in the Sugar
 Stack.

Fairly sure this is not a limitation in Telepathy/Sugar.

The only activity I'm aware of using a hub and spoke topology is  
Write, and I believe a recent AbiWord release has improved the  
collaboration code so that allows a re-election of a new hub, of the  
original goes away (also supports text colour highlighting for  
different users) – very keen to see this land in an image and give it  
a test.

Other activities that support some form of collaboration like Chat,  
Browse, Etoys, TurtleArt, Arithmetic, Maze, Pippy, etc, etc, don't  
care who started the activity first, or who goes away.

Regards,
--Gary

 Either way, I read in your reply that I shouldn't have hopes for it.
 Understood - thanks!


 m
 -- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
 ___
 Devel mailing list
 Devel@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-03 Thread Martin Langhoff
On Tue, Nov 3, 2009 at 2:41 PM, Gary C Martin g...@garycmartin.com wrote:
 Other activities that support some form of collaboration like Chat, Browse,
 Etoys, TurtleArt, Arithmetic, Maze, Pippy, etc, etc, don't care who started
 the activity first, or who goes away.

Are you positive about this? I don't meant to troll -- but I am seeing
issues (with Chat for example) where if the leader goes, 3rd parties
cannot join anymore.

It may be due to a problem somewhere, or it may be that it's just not supported.

If it's expected to work, part of the supported Sugar featureset --
I'll follow it through. If it's not supposed to work, I'll stress
about something else ;-)




m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-03 Thread Benjamin M. Schwartz
Martin Langhoff wrote:
 On Tue, Nov 3, 2009 at 2:41 PM, Gary C Martin g...@garycmartin.com wrote:
 Other activities that support some form of collaboration like Chat, Browse,
 Etoys, TurtleArt, Arithmetic, Maze, Pippy, etc, etc, don't care who started
 the activity first, or who goes away.
 
 Are you positive about this? I don't meant to troll -- but I am seeing
 issues (with Chat for example) where if the leader goes, 3rd parties
 cannot join anymore.

That is remarkable, and worth investigating.  The Chat activity in
particular is designed to survive loss of the initiator, and has been
since the very first release.

One related issue is  http://bugs.sugarlabs.org/ticket/934 .  Once the
initiator leaves, the initiator can no longer re-join due to an issue in
the GUI.  That bug contains a patch, but it's unclear to me whether that
patch was ever applied.  Maybe Tomeu can clarify the situation.

--Ben




signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-03 Thread Tomeu Vizoso
On Tue, Nov 3, 2009 at 15:07, Benjamin M. Schwartz
bmsch...@fas.harvard.edu wrote:
 Martin Langhoff wrote:
 On Tue, Nov 3, 2009 at 2:41 PM, Gary C Martin g...@garycmartin.com wrote:
 Other activities that support some form of collaboration like Chat, Browse,
 Etoys, TurtleArt, Arithmetic, Maze, Pippy, etc, etc, don't care who started
 the activity first, or who goes away.

 Are you positive about this? I don't meant to troll -- but I am seeing
 issues (with Chat for example) where if the leader goes, 3rd parties
 cannot join anymore.

 That is remarkable, and worth investigating.  The Chat activity in
 particular is designed to survive loss of the initiator, and has been
 since the very first release.

 One related issue is  http://bugs.sugarlabs.org/ticket/934 .  Once the
 initiator leaves, the initiator can no longer re-join due to an issue in
 the GUI.  That bug contains a patch, but it's unclear to me whether that
 patch was ever applied.  Maybe Tomeu can clarify the situation.

It wasn't applied because without nobody else giving it a look and
doing some testing it was too risky.

It's not too late to make a new bugfix release that is shipped in
SoaS2 or even in 0.84 on F11 on XO-1.

Regards,

Tomeu


-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...

2009-11-03 Thread David Van Assche
Hey,
   I mentioned this to Walter on IRC the other day, but I'd very much
like to participate in anything telepathy based, especially, maybe
moving to mission control 5 and letting go of the admittedly
antiquated sugar presence now, I do need some guidance though, as I am
by no means  a python guru, though I've really digested telepathy and
have a pretty good feeling for the dbus bindings it has, as well as
the way D-tubes work. I didnt realise the power of having basically
networked dbus until I really got the d-tubes. It even lends a great
deal of power to things like LTSP, by being able to remotely  control
rudimentary elements that are otherwise quite difficult (remote volume
control, rmote power off, remote switch users, remote control of many
kinds... I could imagine almost a remote dashboard... much like italc,
but with more power. and able to do things I havent even thought
about yet I know its exciting stuff though I dont thnink I'll
be able to make it to Bolzano, but I understand there will be  a
strong remote presences... so I'd be happy to help out in that area,

kind regards,
David Van Assche

On Tue, Nov 3, 2009 at 4:30 PM, Tomeu Vizoso to...@sugarlabs.org wrote:
 On Tue, Nov 3, 2009 at 15:07, Benjamin M. Schwartz
 bmsch...@fas.harvard.edu wrote:
 Martin Langhoff wrote:
 On Tue, Nov 3, 2009 at 2:41 PM, Gary C Martin g...@garycmartin.com wrote:
 Other activities that support some form of collaboration like Chat, Browse,
 Etoys, TurtleArt, Arithmetic, Maze, Pippy, etc, etc, don't care who started
 the activity first, or who goes away.

 Are you positive about this? I don't meant to troll -- but I am seeing
 issues (with Chat for example) where if the leader goes, 3rd parties
 cannot join anymore.

 That is remarkable, and worth investigating.  The Chat activity in
 particular is designed to survive loss of the initiator, and has been
 since the very first release.

 One related issue is  http://bugs.sugarlabs.org/ticket/934 .  Once the
 initiator leaves, the initiator can no longer re-join due to an issue in
 the GUI.  That bug contains a patch, but it's unclear to me whether that
 patch was ever applied.  Maybe Tomeu can clarify the situation.

 It wasn't applied because without nobody else giving it a look and
 doing some testing it was too risky.

 It's not too late to make a new bugfix release that is shipped in
 SoaS2 or even in 0.84 on F11 on XO-1.

 Regards,

 Tomeu


 --
 «Sugar Labs is anyone who participates in improving and using Sugar.
 What Sugar Labs does is determined by the participants.» - David
 Farning
 ___
 Sugar-devel mailing list
 sugar-de...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel




-- 

Samuel Goldwyn  - I'm willing to admit that I may not always be
right, but I am never wrong. -
http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel