[sugar] sugar-core for Update.1 - was: What's left for Update.1

[Simon Schampijer]

Things I find worth looking at for update.1 (at least the things that 
are in joyride or we have a fix for):

* In joyride and tested
  - #6046 Browse is slow (rainbow.noarch 0:0.7.9-1.olpc2, 
fontconfig.i386 0:2.4.2-5.olpc2)
  - #5904 Grouping in mesh view: sugar-0.75.11-2.olpc2.i386.rpm
  - #4781 Video/Audio files from Record don't show up on clipboard: 
sugar-base-0.2.2-1.olpc2.i386.rpm

* Have a patch and tested
  - #6127 Browse can't register handler (fix in sugar git master)
  - #6108 Browse crash when X refuses / patch for hulahop attached to ticket

* Unresolved
  - #6133 controls not right in xulrunner beta-2
  - #6308 Browse does not release sound device
  - #6170 Write crash

Best,
    Simon


Jim Gettys wrote:
> For comment and discussion, here are the showstoppers I know of for
> getting Update.1 finished.  If you think there are others, please speak
> up now (and modify the subject line to start another thread).
> 
> Activity developers: note we'll be asking you to upload updated
> activities to pick up all the recent flurry of translation work very
> soon.
> 
>  1 - wireless firmware and driver support 
> 		(to fix problems with WEP and WPA)
>  2 - q2d11 OFW - to fix battery problems
>  3 - update activities to pick up translation work, Spanish 
> 	in particular, but not missing other languages we may need.
>  4 - UI fix for registration with the school server.
> http://dev.laptop.org/ticket/6136
>  5 - switch to gabble from salut at school.
>  6 -testing and fixing anything critical!
> 
> If we don't want to hold up an RC2 to pick up translation, then we
> should anticipate an RC4 might be necessary (as we may have issues that
> come up with updated activities).
> 
> 4 - we previously (without Dave Woodhouse being available to add to the
> discussion) thought we could/should punt #6135 and release note.
> However, talking with him about what we should really fix given his
> experience in Mongolia, the lack of positive confirmation that the
> laptop actually was registered is a real issue.  The teachers are not
> familiar with English (or computers), and the subtlety of a menu entry
> going away isn't good enough.
> 
> I think we need to seriously discuss about possibly/probably being
> update.1 fodder is the "kids arrive at school in the morning" problem.
> 
> 5 - Use of mesh in large, crowded environments
> If everyone arrives at school running local link and resumed quickly,
> the network might melt from mdns mesh traffic's interaction with the
> mesh's implementation of mutlicast.  We've upped the multicast bitrate
> for multicast as a band aid, until we can dynamically adjust the
> bitrate.  But the fundamental issue comes that in large, dense school
> environments, can't expect multicast to scale far enough, and should be
> using unicast to a presence server (jabber in our current case) to
> handle this problem.
> 
> Dave Woodhouse has suggested may be to try to get a response to the
> school server's anycast address, and if we get a response from a school
> server, switch from Salut to Gabble for presence service automatically.
> 
> This is also somewhat mitigated by having working power management, as
> machines that have suspended due to idle stop sending mdns packets, and
> the kids presumably will want internet access and switch over when they
> arrive.  But I'm not very confident that this will always work in large
> environment.
> 
> Another temporary solution would be to have Ohm ask NM to reconnect if
> the machine is suspended for more than some interval, say, 30 minutes.
>