[sugar] sugar-core for Update.1 - was: What's left for Update.1
Fri Feb 8 13:07:38 EST 2008
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,
- #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:
* 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
- #6133 controls not right in xulrunner beta-2
- #6308 Browse does not release sound device
- #6170 Write crash
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
> 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.
> 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
> 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.
More information about the Sugar-devel