Re: [sugar] OLPC + Sugar
On Fri, Dec 12, 2008 at 04:37:18PM -0600, Yamandu Ploskonka wrote: If Brezhnev and Nixon and Mao were able to publish joint statements, we can too. Let's not give up. OK, there must be a couple points we agree on, like, to start, World Peace. I couldn't have imagined something very solid at this stage - at this point what I would see is a sort of a General Notes On An Agreement to Start Conversations to Eventually Sit Down And See What We Can Agree On. Now, if the motivation is really not there, then I guess we're pretty much all wasting our time. Yama, Thanks for your kind reply. I get the impression from the people I talked to here that they're simply buried under other issues right now. I'm not actually sure whether that means it would be good to try again next week, next month, or never. Really, I just wanted to let people know not to hold their breath. :) Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] XO identity shared via Browse
On Tue, Dec 02, 2008 at 03:56:06PM -0500, Greg Smith wrote: We're mostly thinking of the school server as the server side but a more generic solution may be acceptable. I'm relatively comfortable with our vague identity plans for the XS but I'd like to know more about your idea for a more generic solution before going further in that direction. That's one example. I would also like any Web server to be able to extract the XO identity and use it in CGI (e.g. PHP) for processing. What could possibly go wrong? -- anonymous. I put a stub of a requirement for it on our roadmap here: http://wiki.laptop.org/go/Feature_roadmap#Single_Sign_on_from_Browse This seems decent so far. Do you have any ideas or designs for how we can achieve that? We discussed it at SugarCamp. The essential idea from that discussion was to have the XO and the XS exchange certs at registration time so that they can later prove their identities to one another on demand. The tricky bits involve scope, security, users, and maintenance: scope) what are we proving identity to? e.g.: one single XS, ever. one single XS, whichever we're currently registered with several servers at once other XOs what software, on the XO, should be responsible for proving identity? if Browse, how does Browse talk to the registration code? if Browse, what about Gmail, Help, WikiBrowse, ... if something else, how does the something else talk to Browse? when should we make use of an ability to prove user identity? security) who are the principals? what are their goals? what attacks concern us? users) what do we do if something looks wrong? fail silently? log an error somewhere? fail loudly? are there any user overrides? can I turn this off? can I have multiple identities? can I share my identity with someone else? maintenance) what happens if the user loses their laptop and gets a new one? what happens if the server breaks and a new one is installed? what happens if I move from an old school to a new one? what happens when the XO's software is upgraded? downgraded? Regards, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] OLPC + Sugar
Folks, OLPC remains incredibly excited by Sugar and looks forward to a long and productive working relationship with all the other people who share this excitement. Look for a joint statement sometime next week on the new ideas we developed at SugarCamp for strengthening Sugar, SugarLabs, and our partnership. Regards, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] gconf woes
On Sun, Nov 23, 2008 at 05:14:28PM +, Daniel Drake wrote: Hi, The problem is that the sugar module imports try to read the XO nickname, colours, etc, information which is now stored in gconf. But, gconf is a per-user thing, everyone has their own store. How about making a copy (either via cp ... or mount --bind -o ro ...) of the gconf state available to the activity before it starts? Rainbow launches activities as different users, so with the default behaviour we cannot expect activities to be able to access sugar's configuration. We should distinguish between reading that configuration and writing to it. We should also distinguish between writing system-wide configuration and per-activity configuration. Are any parts of the gconf configuration data sensitive? Does gconf offer any support for such niceties? Potential workaround: set ORBIT_SOCKETDIR=/tmp/orbit-olpc in rainbow, and loosen permissions on /tmp/orbit-olpc/* This works, but causes gconf to complain loudly that /tmp/orbit-olpc is not owned by the current user (i.e. the one running the activity) ... Tomeu raised the point that GConf2-dbus would solve this, as it provides a per-session-bus settings repository, rather than a per-user one. Rainbow already shares the session bus between olpc user and activities. Rainbow only shares the session bus between the olpc user and activities because it was necessary to do so in order to achieve anything, not because it's a good idea. Good ideas are more than welcome. What should actually be going on here? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Postponement of XOCamp Event to January
Per Ed's implicit request, I have updated http://wiki.laptop.org/go/XOcamp_2 and http://wiki.laptop.org/go/XOcamp_2/Fundraising to the postponement directive. Michael P.S. - I wish to offer special personal thanks to the six warm-hearted (but cool-headed) donors who pledged to fund travel scholarships for speakers and developers. Your generous act was greatly appreciated. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Donations for travel to Nov 17 XOcamp, also spare bedrooms needed!
I wish to add two things to what Scott wrote: First, two purposes for the conference have been recognized to date: 1) to facilitate planning relevant to 9.1 and beyond, 2) to build trust and relationships between community members. Given present realities, three options have been proposed: a) travel scholarships b) postponement, e.g. to Fudcon in January c) remote participation We all recognize that goal (1) can be conducted effectively by remote means (c) but I doubt that goal (2) can be achieved in this fashion. The question is therefore how to provide for goal (2). While I could certainly accept a consensus forming around option (b), I happen to think that (2) is so important that, like Scott, I would be honored to fund travel and to supply room and board for one or two scholarships if others felt the same way. Regards, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Persistent activity storage (Bert Freudenberg)
On Tue, Oct 21, 2008 at 09:55:38AM -0400, Greg Smith wrote: Hi Michael et al, I thought that starting an activity from the Home View would start it with no state preserved from the last time it was used. Starting it from a Journal entry would start it with the state of the saved (kept?) instance, including any files that we worked on before. What you describe is implemented today but that is not what was designed: http://wiki.laptop.org/index.php?title=Designs/Activity_Managementoldid=112067#07 I'm simply saying that we should try more fully implementing the design so that we can make an better decision about which interaction model is superior. In the first instance it may be useful to preserve some settings or options but probably not wise to always open with the same file. Both 'resume' and 'clone a prototype' are useful actions; however, some people (me, Walter, ...) think that 'resume' is a better default. 'clone a prototype' is like 'new' but works better with user-editable templates or examples. What kinds of persistence are we talking about here? Persistence of the 'bottles' that Rainbow makes. Also, are there any activity launch time performance concerns? I have activity launch concerns (performance and otherwise) in many other places, but not here. I want to make sure we don't slow down the launch time without a very good reason. Well, how much risk and how much of Marco's, my, and Tomeu's time do you think we should squander on supporting hacks to make activities launch quickly? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Persistent activity storage
On Tue, Oct 21, 2008 at 09:34:00PM -0400, Mikus Grinbergs wrote: I want to make sure we don't slow down the launch time without a very good reason. Well, how much risk and how much of Marco's, my, and Tomeu's time do you think we should squander on supporting hacks to make activities launch quickly? I do not think making the machine appear to be more snappy is 'squandering' of resources. Nor do I; my emphasis was on the 'supporting hacks'. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Security and Isolation
On Mon, Oct 20, 2008 at 10:46:37AM +0200, Tomeu Vizoso wrote: On Fri, Oct 17, 2008 at 9:53 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: * Persistent activity storage What does this mean? That when you resume an activity, it should come up with the same uid it had when you launched it, and with the same instance/ dir. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Persistent activity storage
On Mon, Oct 20, 2008 at 01:36:06PM -0500, Yamandu Ploskonka wrote: It would be way nice it also came back to the same page, if you are reading a book Yes, that's also a goal, though it will certainly require activity-level changes. When I spoke about this with Marco, we tentatively agreed that we would try to create a new (unstable) activity API in parallel to the old one so that activity authors would have a longer period of time (the deprecation period) to port to the new API. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Persistent activity storage
On Mon, Oct 20, 2008 at 09:25:40PM +0200, Bert Freudenberg wrote: Am 20.10.2008 um 21:12 schrieb Michael Stone: On Mon, Oct 20, 2008 at 01:36:06PM -0500, Yamandu Ploskonka wrote: It would be way nice it also came back to the same page, if you are reading a book Yes, that's also a goal, though it will certainly require activity- level changes. Err - hasn't that been a requirement from the beginning? I thought that any activity not storing its full state and thus not resuming to the exact same state was violating the system rules. Correct. Michael (Perhaps you are suggesting that all current activity implementations conform to this requirement?) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Launching activities from other activities
On Mon, Oct 13, 2008 at 08:45:54PM +0530, Sayamindu Dasgupta wrote: Hello, What would be the best way to launch any activity from another activity ? An example where this is required would be #8774 where teachers from Uruguay are complaining that they are not being able to directly open hyperlinks embedded in PDFs from Read. Ideally when the user clicks on the link, Browse should start and show the relevant page. I wrote a small utility called sugar-open yesterday, similar to gnome-open and xdg-open, where you pass any uri to the tool, and it will try to open it with the first relevant Activity it can find. I'm planning to make Read invoke sugar-open and launch Browse if required. Is there any better way to do this ? Thanks, Sayamindu Sayamindu, Where can I find your script? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Annotation (was Re: Viewing PDFs from Browse)
On Mon, Oct 13, 2008 at 11:02:03AM -0400, Samuel Klein wrote: Annotation is different from editing and original creation. Unless you are being intentionally vague (as I often am), please be more precise. I argue that since annotation is clearly comprised of both editing and original creation of a new work based on or in reference to some older works, it cannot be _wholly_ different from both editing and original creation. A user can in fact annotate a file or document they do not have locally. I don't believe you -- or perhaps I simply reject your usage of the word have. Example, please? I find that use case more likely than the alternative; I have never succeeded in pushing a book report upstream into a publisher's next edition. a) You've never contributed errata to an author? b) I imagine, perhaps incorrectly, that remote annotation works best with a cheap well-functioning network. Do you agree? Annotation, commentary, and review should be cleanly separated from [ownership of] the original document or media file. No comment yet; let's see where you go with this. A set of annotations is in general much smaller on disk, Why would you assume that annotations occur in the same medium as the original work? For example, I could easily imagine calling a video-taped lecture about a book or collection of photos an annotation. much more frequently versioned, Evidence or reasoning please? and more likely to need sharing (rather than independent discovery of copies of the same work) than originals. This also makes little sense to me. A set of annotations made to one version of a document are also relevant to other versions, They are sometimes relevant; it seems to me to depend on the rate-of-churn of the annotated work. Another problem is that it's often unclear whether you want to annotate a work or the context in which the work occurred. Conversely defining annotations such that they exist separately from a document helps make different sets of annotations overlay with one another. Perhaps, but it also tends to curtail their visibility. To use your image-drawing example, if there is an original image that I can expect others to have seen, and I am drawing on top of it, I would indeed hope that the drawing is stored in such a way that the original can be deciphered _Why_ do you prefer immutable history to destructive updates? I can do rather things with liberal application of scissors, paint, and glue which are just as valuable (though they are non-invertible) as the things I can do with my version control system. (The point being that destructive updates are fine to me, and if history is needed, then they can be applied to a copy.) -- so that if you and I draw different things, I can tell that it was on the same image, It's not necessary for the original content to be _decipherable_; it's enough for the original content to be _recognizable_ should you encounter it again (or want to go looking for it). or add our two drawings together, or switch from mine to yours simply by exchanging drawing layers rather than exchanging the entire image. If you store my mona lisa mustache by modifying the mona lisa in place on my machine, this is hard to separate out in the future. So what? If your system is too hard to build or to run then I probably wouldn't have been able to draw my mona lisa mustache in the first place, in which case we'd both be poorer. After passing through a world with millions of works and terabytes of data, the small part of this that I hope to preserve as my own gloss and memory of it, the part I might keep in a real journal, is effectively my set of annotations, assessments, margin notes : these should be built deeply into [Sugar], and the usability and sharability of them refined. Great; have you got your own programmers for this task, are you trying to tempt folks here, or both? (I inquire because your email seems to me to be suited to neither of these audiences.) See also [[annotation]] on the wiki, for the above and for discussion of how to link annotations to words, pages, collections, collaboration sessions, and projects; similarities b/t comments, discussions, annotation and review; c. Prior work in this area is worth citing; to that end, I have created an appropriate section at the bottom of your [[Annotation]] page. If you actually want to build something here, then please help fill it out. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Putting stuff inside the datastore for non-activities
Thanks for the tip. It looks like for remote files, mozplugger is creating the tmpfile in instancedir/tmp mozplugger is probably reading $TMPDIR, which we set. You can change that setting if you want. Next, the DS is unable to copy the file content of the file in $SAR/tmp because the tmpfs mounted on $SAR/tmp is not mounted in the namespace being used by the DS. Michael P.S. - Feedback on other file-layouts would be appreciated; this is one of the areas which I have considered revising for 9.1. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
Bill, Here's a short dialogue between myself, Ben Schwartz, Martin Dengler, and Bobby Powers on my interpretation of narrative as it might apply to a user interface designed for engaging children in the world of learning: http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 === Highlights * By narrative, I mean a rational sequence (or graph) of events. * It's rather hard to use XOs to prepare direct lessons. By direct lesson, I mean a guided learning experience, usable in variable network conditions, which minimizes the amount of decision-making and navigation that the end-user needs to perform in order to experience 'the whole thing' regardless of what software implements each individual experience contained in the lesson. === Toy Problem Concretely, suppose I invent a new Python trick like the ones at http://wiki.laptop.org/go/User:Mstone/Tricks How might a prepare a slick explanation for an inexperienced user? * I might write up a web page for my trick, then write a Pippy bundle showing off the trick in a toy program, then give a pointer to a git repo containing an instance of the trick in 'production'. Question: How do I write web pages on an XO? Question: Do I have to be able to read in order to find and run the Pippy bundle? * I might write up a larger Pippy example for my trick in the literate style. I might also create a puzzle revolving around integrating the trick into some sample code. I might include links to 'advanced reading' or more examples in comments in the source code. Question: Pippy doesn't know anything about hyperlinks. Will my readers? Question: I must either comment out my puzzle so that the example can run or I must provide it in a separate bundle. How many users would figure out how to try both the example and the puzzle? * While not obviously applicable to this specific example, two other common solutions to this sort of problem include the scripted transitions between freeform experiences idea common to wizards and role-playing games and the 'build a custom but user-editable program' idea underlying most EToys lessons. === Larger Concerns Since Sugar is strongly concerned with UI unification, it's worth spending more time thinking about how well each of the solutions to your favorite toy problem integrates with encompassing narratives of reflection, criticism, and human collaboration. (None of the solutions I've proposed above satisfy me in any of these regards.) In any case, I hope this followup helps explain the motivation and 'line-of-thought' behind my initial email. Please discuss. Regards, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Narrative.
Bryan Berry wholly captured my attention tonight when he said (in summary): Sugar offers an excellent mode for discovery but no excellent way to manipulate narratives. Both discovery and narrative are essential for learning. [1] This statement seems to me both indisputable and damning; if true, it strikes to the core of the claim that Sugar is appropriate for learning. Even though Bryan has already found some partial solutions to this problem [2], we should take time to debate the more primitive thesis that: Narrative is a basic component of much educational material which Sugar ought to 'natively' recognize, respond to, and manipulate. so that we may decide whether this issue should receive a greater share of our limited design and implementation resources. Regards, Michael [1]: Sugar presently records actions which may occasionally be decomposed into narrative or situated within an external narrative; however, Sugar is presently blind to these relationships. [2]: Bryan is currently encoding narratives in HTML and is attempting to use Offline Moodle to make this cheaper to support. I decided to write this email because I believe that it might well be worth our time to either give him a hand with his effort or to bake support for similar use cases directly in to Sugar. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Signed candidate-765 and gg-765-2 builds available for testing.
After checking with Joe this evening and having previously discussed the necessary security signoffs with Mitch, Richard, Scott, Andres, and Deepak, I have decided to publish 8.2-765 as a signed Candidate in the interests of spurring easier and more widespread testing over the weekend. I have also published gg-765-2, a signed G1G1 candidate composite image, created by Scott. gg-765-2 is similar to what we hope to put into manufacturing next week. http://download.laptop.org/xo-1/os/candidate/765/ (raw os) http://download.laptop.org/xo-1/custom/g1g1/gg-765-2/ (G1G1 composite) olpc-update candidate-765 (olpc-update) http://wiki.laptop.org/go/Friends_in_testing (the usual) http://wiki.laptop.org/go/Customization_stick (make your own) http://wiki.laptop.org/go/Image_builder (next steps) http://wiki.laptop.org/go/Software_update (activity groups) Enjoy, Michael P.S. - You should expect an 8.2-766 with minor changes either over the weekend or on Monday; however, it will be substantially the same as 765, so please get started on 765 now. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Another pass through some basic Activity test results
It seems that mangling occurred; however, I repaired it and have temporarily published the results here: http://teach.laptop.org/~mstone/gary.txt Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Wed, Sep 24, 2008 at 04:16:17PM -0400, Walter Bender wrote: We all agree that the datastore needs serious attention, although it doesn't directly impact the running of legacy activities. Rainbow is an issue. And moving data back and forth between Sugar and legacy apps is an issue. Please say more. Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Composition -- we've been here before!
On Wed, Sep 24, 2008 at 09:45:44PM -0700, Bert Freudenberg wrote: At least this one has been fixed 4 months ago. Sure. I brought it up because, to me, it serves as a useful reminder of the careful regression test that enabling composition will require and of how few people really understand how the XO's graphics code works. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Please help test our new best 8.2.0 candidate, 8.2-763!
You'll know that we're nearing the end of our arduous 8.2.0 release cycle when you see the polish and features in our new candidate build, 8.2-763, valid until Wednesday, September 30 [1]. Its changelog (from 759) is available here: http://lists.laptop.org/pipermail/devel/2008-September/019564.html http://lists.laptop.org/pipermail/devel/2008-September/019571.html http://lists.laptop.org/pipermail/devel/2008-September/019616.html Please help test it according to the detailed instructions at http://wiki.laptop.org/go/Friends_in_testing while we still have time to document any issues that you might find! Next, please hammer on the list of activities and content that we currently intend to ship: http://wiki.laptop.org/go/Activities/G1G1/8.2.0 (will be updated tomorrow) (NB: the activity updater should pull all this down for you, if you ask it) Currently known issues are recorded at: http://wiki.laptop.org/go/Test_Group_Release_Notes#Build_8.2-763 and in the usual http://wiki.laptop.org/go/Trac_queries New issues should be filed in our bug-tracking system (dev.laptop.org) according to http://wiki.laptop.org/go/Submitting_bugs or by notifying us by other means. Finally, for those of you anxiously waiting to test 8.2.0 builds on locked laptops, we expect to have a signed build for you this week. Watch http://wiki.laptop.org/go/ECO/8.2.0 for progress. Thanks! Michael [1]: The multi-hundred-thousand-laptop question is: 2008 or 2009? :) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
My impression, based on historical conversations with the parties involved is that there are a bunch of hackers who feel that we did ourselves a disservice by dropping _so much_ backwards compatibility, specifically with Unix filesystems and desktops, in exchange for cool ideas. The feeling is that had we traded compatibility for features less aggressively then there would be many more hackers available to help write the features since there would be many more hackers who felt it was possible to live within Sugar. This is just an impression, however. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Finale: consider merging a few fun Sugar patches?
On Thu, Sep 18, 2008 at 01:23:57PM +0530, Sayamindu Dasgupta wrote: On Thu, Sep 18, 2008 at 6:06 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2008 at 2:30 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: * At *very* high level the patch sets looks sane. I would be comfortable with them going in if Scott reviews Martin set, and Martin reviews Scott set. * The patches are large and I don't think it's impossible that they would cause regressions. Our release manager should be aware of it and keep loving us if it happens. * I would help by getting packages in the builds and doing a bit of testing. * Both patches contains string additions I guess (hopefully not changes?). Someone would have to sort that out with sayamindu and the localization team. String addtions ?? Now ?? -sdg- Sigh. I knew I was forgetting something important. I guess these can be first-on-deck for 8.2.1 then. :( Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Finale: consider merging a few fun Sugar patches?
Folks, We've reached the last call for changes before final test and, in the hopes of ending our development cycle on a playful note, I'd like to ask the sugar team to consider whether they'd be comfortable reviewing and merging a couple of the outstanding UI patches like Scott's alternate layouts patches [1] and Martin's network feedback patches [2]. Sugar team: you can nix the idea if it seems too risky, if the patches aren't baked, or if it would take too much time to accomplish, but if you're willing to step up and handle the review, merge, and testing, then I think it would a joyous finale to a remarkable development cycle. Regards, Michael [1]: http://dev.laptop.org/git?p=users/mdengler/sugar;a=shortlog;h=network-feedback-2866 [2]: http://dev.laptop.org/git/users/cscott/sugar P.S. - (The deadline for this action, should you choose to accept it, would be Friday afternoon.) P.P.S. - Eben mentioned to me that he was concerned that people might falsely interpret some of the new 8.2.0 Sugar APIs as stable when they are, in fact, almost certain to change in the next major release. I would find it commendable if some Sugar developer took this last opportunity to add some bold comments to the relevant APIs warning developers who examine them about this probable future breakage. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Finale: consider merging a few fun Sugar patches?
On Thu, Sep 18, 2008 at 02:30:30AM +0200, Marco Pesenti Gritti wrote: * At *very* high level the patch sets looks sane. I would be comfortable with them going in if Scott reviews Martin set, and Martin reviews Scott set. Sounds good. Hopefully there are a few other sugar volunteers who could chip in to help look for regressions? * The patches are large and I don't think it's impossible that they would cause regressions. Our release manager should be aware of it and keep loving us if it happens. I'm the one who'se suggesting it, so I'd take the blame. * I would help by getting packages in the builds and doing a bit of testing. This can happen immediately, yes? P.P.S. - Eben mentioned to me that he was concerned that people might falsely interpret some of the new 8.2.0 Sugar APIs as stable when they are, in fact, almost certain to change in the next major release. I would find it commendable if some Sugar developer took this last opportunity to add some bold comments to the relevant APIs warning developers who examine them about this probable future breakage. Eben, what APIs are you thinking about? In general the whole Sugar API will need to be reviewed. I have yet to figure out when, how and what kind of backward compatibility we offer. It's something I'll be working on in the next few weeks. Eben specifically mentioned the APIs used by Frame devices, layouts, and Control Panel entries. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Closing up 8.2.0.
Dear devel@, This is your notification of our serious intent to release 8.2.0 within the next three weeks, if possible. * This week, we intend to publish an unsigned raw OS and an unsigned G1G1 derivative image for testing. We will begin our the first-boot activation security audit on this image. We also hope to publish draft release criteria. * Next week, we hope to feel ready to publish a signed candidate raw OS and signed G1G1 derivative image. These candidates will undergo widespread testing and will be at genuine risk of being released. * PLEASE offer your tickets under the 'approval for release' action if you have changes that need to be included. See http://wiki.laptop.org/go/Trac_ticket_workflow for details. * PLEASE continue to offer the same dedication and contribution quality you've demonstrated of the last four weeks as you fix blockers, polish, analyse memory-pressure, conduct exploratory and systematic testing, and improve our documentation -- you're doing wonderful work and we're all going to really proud (and glad!) of it in just a few short weeks. Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Please help test our new best 8.2.0 candidate, 8.2-759!
We got an awesome new 8.2 candidate build, 8.2-759, valid until Wednesday, September 10. Its changelog is available here: http://lists.laptop.org/pipermail/devel/2008-September/018843.html (except that we decided to hold off on the #7415 patch) Please help test it according to the detailed instructions at http://wiki.laptop.org/go/Friends_in_testing while we still have time to fix issues you might find! Next, since we've done a lot of documentation work over the past few weeks, it would be really helpful if you could glance at our manuals and release notes: http://en.flossmanuals.net/XO http://en.flossmanuals.net/Sugar http://wiki.laptop.org/go/Release_Notes/8.2.0 to looking for discrepancies that need to be fixed. Currently known issues are recorded at: http://wiki.laptop.org/go/Test_Group_Release_Notes#Build_8.2-759 New issues should be filed in our bug-tracking system (dev.laptop.org) according to http://wiki.laptop.org/go/Submitting_bugs or by notifying us by other means. Thanks! Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Trac ticket workflow updates.
Friends, As we wind down toward the end of the 8.2.0 release cycle (and begin to tighten our change control), we must make a few tweaks to the Trac ticket workflow. I have written up the new workflow in great detail at http://wiki.laptop.org/go/Trac_ticket_workflow The highlight is three new 'action needed' states: 'approval for release', 'add to release', and 'test in release' whose meanings are, I hope, apparent. Please reply with any resulting questions, comments, suggestions, or gripes. (Oh, and please help fill in the linked-to pages!) Regards, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Please help test our new 8.2.0 Alpha release candidate, 8.2-757!
We are thrilled to announce our zeroth (Alpha) 8.2 release candidate, 8.2-757, valid until Wednesday, September 3. Please help test it according to the detailed instructions at http://wiki.laptop.org/go/Friends_in_testing while we still have time to fix issues you might find! Next, since we'd love to start generating per-activity release notes this week, please help us determine: Are there any caveats about running Activity (perhaps alongside or Activities and or in Language ) that everyone should know? Currently known issues are recorded at: http://wiki.laptop.org/go/Test_Group_Release_Notes#Build_8.2-757 New issues should be filed in our bug-tracking system (dev.laptop.org) according to http://wiki.laptop.org/go/Submitting_bugs or by notifying us by other means. Thanks! Michael P.S. - Our systematic testing effort is slightly closer to ready for primetime and is now described by a summary page at http://wiki.laptop.org/go/Systematic_testing which links to everything important. In short, if you're feeling especially brave this weekend, improving this page with a full-blown walk-through would be a great way to chip in. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Please review recent rainbow patches.
Folks, I've got a small flurry of rainbow patches (everything from rainbow-0.7.19..HEAD in http://dev.laptop.org/git/users/mstone/security) that could use a bit of review. Many thanks, Michael P.S. - http://teach.laptop.org/~mstone/rainbow.rpm is an RPM containing these patches. It's as yet untested, so I may well have broken things; however, fixing that can happen in parallel with the review. :) P.P.S. - I still haven't figured out how to really fix #8016 except by excruciatingly dirty hacks. Any thoughts would be appreciated. :( ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] is there something that eats develop.sig ?
On Fri, Aug 22, 2008 at 05:17:53PM -0400, Mikus Grinbergs wrote: Is there any documentation about when develop.sig would be erased ? Because our NAND is unpartitioned, reflashing the NAND means that you lose _all_ data stored on NAND. To avoid this problem in the future, either keep your developer key on a USB stick or type 'disable-security' at the OFW ok prompt. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Trac #7480: Need to 'reset' the network configurations - short term fix
On Tue, Aug 12, 2008 at 01:23:07PM -0400, C. Scott Ananian wrote: I moved discussion back to http://dev.laptop.org/ticket/7480 , including citing Morgan's objections quoted above and proposing a solution. Does anyone want to implement an email-trac gateway, like debian's bug tracker has? That would help a lot when discussion veers off into email. Ask and ye shall receive: http://trac-hacks.org/wiki/EmailtoTracScript Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Trac #7480: Need to 'reset' the network configurations - short term fix
On Mon, Aug 11, 2008 at 09:31:26PM -0400, Erik Garrison wrote:
Attached is a patch which adds a 'reset network configuration' button to
the network tab of the sugar control panel.
Thanks very much for the patch, and for the thoughtful design.
+n = 1 + max(map(lambda x: int(x.replace('networks.cfg.bak.', '')),
+network_cfgs))
This expression, while cute, is unsafe and will result in failure if you
ever encounter a file with a name like 'networks.cfg.bak.hi'. Please
write total code or handle exceptions appropriately.
(Incidentally, does anything bad happen if your code does happen to
generate exceptions?)
Regards,
Michael
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Trac #7480: Need to 'reset' the network configurations - short term fix
On Thu, Aug 14, 2008 at 11:12:09AM -0400, Erik Garrison wrote:
On Tue, Aug 12, 2008 at 12:02:41AM -0400, Michael Stone wrote:
On Mon, Aug 11, 2008 at 09:31:26PM -0400, Erik Garrison wrote:
Attached is a patch which adds a 'reset network configuration' button to
the network tab of the sugar control panel.
Thanks very much for the patch, and for the thoughtful design.
+n = 1 + max(map(lambda x: int(x.replace('networks.cfg.bak.', '')),
+network_cfgs))
This expression, while cute, is unsafe and will result in failure if you
ever encounter a file with a name like 'networks.cfg.bak.hi'.
The solution is to guarantee that inputs are of the correct form
(networks.cfg.bak.\d+$). As follows, two lines previously should be:
network_cfgs = [file
for file in os.listdir('/home/olpc/.sugar/default/nm')
if re.match('networks.cfg.bak.\d+$', file)]
Please write total code or handle exceptions appropriately.
I don't understand what you mean by 'total' code.
Total (as opposed to partial) functions, programs, expressions, etc. are
defined for every possible input rather than for only some of their
inputs. The way you defined network_cfgs was partial in that, in
addition to generating an exception, it also left n undefined (not
even set to None) for some inputs (such as those I described).
You do not need to ask me to write bug-free code.
There are actually lots of people (including myself) who I find I have
to ask to write bug-free code (often concerning race conditions).
However, I'm glad to hear that you care deeply about it as well.
Please just say 'I found a problem' and update the patch.
As you prefer.
Michael
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Trac #7480: Need to 'reset' the network configurations - short term fix
On Thu, Aug 14, 2008 at 11:44:12AM -0400, Erik Garrison wrote: Michael, Sorry to be so testy, it was completely unecessary to nitpick your comments! No apologies needed. I'm worried that I won't have time to update this patch and get the work done for Perú today and tomorrow. Concentrate on Perú. I'll find someone else to do this work and, if I fail, we'll just have to live with the consequences of ѕending you to help Perú. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Please help test our new 8.2.0 weekly beta, joyride-2301!
We are thrilled to announce a new test build, joyride-2301, valid until Wednesday, August 20. Please help test it according to the detailed instructions at http://wiki.laptop.org/go/Friends_in_testing while we still have time to fix issues you might find! Our specific interest this week has changed; this week, we'd love to know: How many ways can you crash or hang your XO? Currently known issues are recorded at: http://wiki.laptop.org/go/Test_Group_Release_Notes#Build_joyride-2301 New issues should be filed in our bug-tracking system (dev.laptop.org) according to http://wiki.laptop.org/go/Submitting_bugs or by notifying us by other means. Thanks! Michael P.S. - I was asked to include to specific notices in this email; first, that http://wiki.laptop.org/go/Software_update gives full details on the new Sugar Control Panel Activity Updater and second, that we are hoping in future weeks to offer a new Coordinated Testing volunteer opportunity as part of the run-up to the 8.2.0 raw OS release. Poke me, Kim, Joe, Charlie, S Page, Seth, or Francesca for details. Sneak preview: http://wiki.laptop.org/go/Test_cases_8.2.0 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Please help test our new 8.2.0 weekly beta, joyride-2263!
On Sun, Aug 10, 2008 at 04:37:50PM -0400, Kevin Cole wrote: I decided to try the clean-install. It took me a few tries to figure out I needed to put my developer key back where it belonged if I wanted to boot without the USB drive. Many developers, in your position, disable the boot-lock with the OFW word 'disable-security'. Others rely on olpc-update, which does not remove developer keys. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Please help test our new 8.2.0 weekly beta, joyride-2263!
We are thrilled to announce a new test build, joyride-2230, valid until Wednesday, August 13. Please help test it according to the detailed instructions at http://wiki.laptop.org/go/Friends_in_testing while we still have time to fix issues you might find! Our specific interest this week continues to be activity compatibility: Does your favorite activity still run on joyride-2263? Currently known issues are recorded at: http://wiki.laptop.org/go/Test_Group_Release_Notes#Build_Joyride_2263 New issues should be filed in our bug-tracking system (dev.laptop.org) according to http://wiki.laptop.org/go/Submitting_bugs or by notifying us by other means. Thanks! Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Please help test our new 8.2.0 weekly beta, joyride-2263!
On Thu, Aug 07, 2008 at 02:45:56PM -0400, Michael Stone wrote: We are thrilled to announce a new test build, joyride-2230, valid until Wednesday, August 13. Apologies for the text substitution failure. The correct build is, in fact, joyride-2263. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Please help test our new weekly test build!
We are thrilled to announce a new joyride-weekly test image, joyride-2230, valid until Wednesday, August 6. Please help test it according to the detailed instructions at http://wiki.laptop.org/go/Friends_in_testing while we still have time to fix issues you might find! Our specific interest this week is on activity compatibility: Does your favorite activity still run on joyride-2230? Currently known issues are recorded at: http://wiki.laptop.org/go/Test_Group_Release_Notes#Build_Joyride_2230 New issues should be filed in our bug-tracking system (dev.laptop.org) according to http://wiki.laptop.org/go/Submitting_bugs or by notifying us by other means. Thanks! Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Notes from today's Release Meeting(s)
On Tue, Jul 29, 2008 at 09:49:23PM -0700, S Page wrote: Michael Stone wrote: 5. Separately, I wish we were receiving even more volunteer testing. Can you help out? Fame, glory, and the undying gratitude of hundreds of thousands of children await you! Background: I'm just a G1G1. I don't have a Developer key, but on my own initiative I installed candidate-703 and candidate-708 using olpc-update and provided some feedback and bug reports. ... More clarity. Is more clarity needed more in some fora than in others? Is this nominated Wednesday build going to be a candidate build that mere users can install using olpc-update, or do I need the fabled bronze Developer key to become a joyride-like tester of nominated 8.2 builds? It will soon, but not yet. In a few weeks, once we're more confident in the sustainability and security of the build, then we'll publish an official candidate build with cryptographic signatures that mark it as suitable for mass installation. and that cloning/updating the Friends in Testing page would be useful. I'd never heard of http://wiki.laptop.org/go/Friends_in_testing I've never heard of X is a rather consistent refrain. Hrm. I did sign up for http://wiki.laptop.org/go/8.2.0#Put_Your_Name_Here_to_Confirm_You_Will_Try_the_Release_Candidate Thanks! I think once OLPC has a candidate build that people can install using olpc-update and has been smoke-tested, then it can publicize it on planet.laptop.org, olpcnews.com, forum.laptop.org, etc. Another mailing list won't help as much to get the word out. Okay. I'm not so sure. If you want more testing, just publicize as above. I didn't hear about candidate builds until I started following devel and figured out the wiki's green Latest Releases box. Should we make the Latest Releases box more prominent or readable? Me too, especially if there's clarity about olpc-update vs. the fabled developer key. You should probably request a developer key: http://wiki.laptop.org/go/Developer_key It will make your life as a tester much, much easier. Besides - Forth is fun! Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Random observations with joyride-2225 and latest activities
On Wed, Jul 30, 2008 at 03:05:18PM -0400, Daniel Drake wrote: On Tue, 2008-07-29 at 09:32 +0200, Christoph Derndorfer wrote: a) Record: using v56 the activity starts up fine, the display shows whatever the camera is capturing, I can go into fullscreen-mode, switch to different tabs, etc. However once I press the capture-button the whole thing basically freezes, sometimes I was still able to move the mouse but clicking wouldn't have any impact, at other times Sugar completely froze and I had to do a hard reset of the XO. Your save-nand image loaded onto my XO just fine, but Record worked fine. Must be something hardware related. very odd. It could also be hardware independent but non-deterministic. Or deterministic but triggered under input that you didn't give. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] joyride-weekly: joyride-2230
Dear world, This week's 'please test this joyride' is joyride-2230. Test group release notes, care of Charlie, are available at http://wiki.laptop.org/go/Test_Group_Release_Notes#Build_Joyride_2230 I'll push this announcement out further as discussed in last night's email as soon as I'm able. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Notes from today's Release Meeting(s)
1. We're going to begin nominating this week's 'joyride-weekly' tomorrow at 0900 EDT. If you have risky changes you want to contribute, please provide them _after_ we deliver our nomination. If you want to help more peoples' changes make the deadline, then please help smoke-test joyrides built close to the deadline. Please record your results on http://wiki.laptop.org/go/Test_Group_Release_Notes and file bugs liberally. When we deliver the build nomination, we will summarize the currently available testing notes in the announcement mail. 2. This week, we will submit the nomination announcement in the following venues: devel@, testing@, support-gang@, the 1cc whiteboard, OLPCNews, forum.laptop.org, and locations on the wiki TBD - the front page Latest releases box - the test group release notes page In addition to a summary of current testing notes, the announcement will include a pointer to testing instructions. (Feel free to help write testing instructions if you've ever been frustrated with the current ones.) 3. We would be really happy if we felt comfortable entering code freeze (a.k.a. package-level change control) next Wednesday. We will make this decision in our Tuesday release meeting. Our fine colleagues in QA have agreed to assist us in making this decision by smoke-testing one fresh joyride per day. 4. In preparation for the full-blown regression tests that we will run in coming weeks, it would be very helpful if we received more detailed package-level ChangeLog entries and if we did better job of displaying the ChangeLog and related-tickets data that we currently have available. (In addition, anyone who further improves Reinier's, Bert's, and Marco's announcer scripts will earn a drink or treat from me.) 5. Separately, I wish we were receiving even more volunteer testing. Can you help out? Fame, glory, and the undying gratitude of hundreds of thousands of children await you! 6. We need to begin settling on an activity pack to use for testing purposes. Suggestions on peaceful ways to identify the contents of this activity pack would be appreciated. Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Notes from today's Release Meeting(s)
On Tue, Jul 29, 2008 at 09:32:42PM -0400, Ton van Overbeek wrote: I (just an interested G1G1 owner for my grandson with a Solaris/Unix/Linux background) would love to help testing, but you are not making it very easy. What would make it easier for you? I gather that having the nominated Wednesday build helps and that cloning/updating the Friends in Testing page would be useful. Anything else come to mind? You have to follow devel@ to know what is going on and that alone is almost a part-time job. Several folks (rsmith and cscott) suggested making at least a devel-announce list for this sort of traffic. Would that help? (Previous requests for volunteer list summarizers were not fulfilled.) On the wiki there is a Friends in testing page (http://wiki.laptop.org/go/Friends_in_testing) but it does not seem to be used by the core developers/testers/release team. It's simple forgetfulness; most of those people follow [EMAIL PROTECTED] :) There has only been one request for testing WiFi compatibility for 8.1.1, but nothing for testing 8.2. 8.2 has only recently (a few weeks ago) become worth booting. Frankly, I've been too overwhelmed with Sugar bugs to pay close enough attention to wireless issues. I believe you really need some dedicated person as liaison between sugarlabs/1cc and outside testing and development volunteers. We agree -- we just haven't found such a person yet. We even have a job description for such a person, though (argh!) it doesn't seem to be posted at http://laptop.org/en/jobs.shtml. Anyway I'll try to test whatever build you nominate tomorrow. Thanks so much! Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] TuxPaint woes
On Mon, Jul 28, 2008 at 11:26:28PM -0400, [EMAIL PROTECTED] wrote: the obvious answers are that we need to commit to some level of continuing support for activities, What notion of support would you suggest? that we support the activities ourselves, As above. or that we need to provide an extensible system so that activities can specify their dependencies (which will either lead to their fulfillment, or to the explicit disabling of the activity if they can't be fullfilled). Constraint satisfaction (i.e. dependency checking) is certainly one approach; however, it is not universal; i.e. similar results can be achieved with usage-outcome reporting technology driven by both manual and automated regression testing. See http://gsoc-sugarbot.blogspot.com/ for some active work in this direction. so far OLPC hasn't specified a minimal level of supplied services, or offered a way for activities to explicitly request services they know to be required. On the other hand, it would be rather trivial for activities which cared to check their dependencies in a adhoc fashion (by running rpm themselves if they wish) and by reporting errors if necessary dependencies are unsatisfied. do you really think we can expect activity developers to maintain their code in reaction mode, having to adapt to any change we make from release to release, only finding out about the breakage after the fact? I actually think that we [SugarLabs] should adopt an approach similar to that taken by the Linux kernel (loosely paraphrased as): we're going to make breaking changes but if you push your drivers [activities] upstream, we'll help carry them along... According to this suggestion, OLPC would contribute to the maintenance of activities which are important to it as would any other employer of SugarLabs coders. Overall responsibility for maintaining SL-designated activities would rest with the SugarLabs community itself. can't think of a faster way to make developers give up on our platform as a lost cause. You need to be more imaginative. :) Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] RTL blocker for 8.2.0?
Marco, Thanks for asking for clarification on this issue. At present, Greg and I disagree about whether this cluster of issues should block the 8.2.0 release and are working with Kim and Robert to resolve our disagreement. However, in order to make good decisions, it would be very helpful if the Sugar/X team along with Sayamindu (and any other people interested in the issue) could write up a short essay explaining all of the current bugs in this area, what plans we could pursue in order to close them, and what it might cost to exercise each plan. In the meantime, I will remove the blocks:8.2.0 tag from these tickets until we reach our decision. Sorry for the miscommunication, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] joyride-weekly builds for testing.
As part of our gradual stabilization program, each week, we're going to nominate the newest non-disqualified Tinderbox-approved joyride build available as of 9:00 AM EDT on Wednesday as the joyride-weekly test candidate for people who are unable to contribute test results against joyride-latest. Please do everything in your power to ensure that builds at risk of being nominated are worthy of these testers' consideration. Or else. :) Finally, this week's joyride-weekly build is joyride-2200. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity launch time testing
On Tue, Jul 22, 2008 at 12:40:59PM +0200, Tomeu Vizoso wrote: Ooops, does that mean that we are much slower in most cases? Is the rainbow trick working here? The rainbow hack is almost certainly not working because no one has fixed it to deal with the fast X startup in our F-9 builds. One approach on how to fix it is to teach rainbow how to talk to upstart. You can see my first thoughts on this approach at http://teach.laptop.org/~mstone/rainbow-job Unfortunately, I'm no upstart expert and I'm somewhat preoccupied with other matters. Does anyone care to take up this challenge in my stead? Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Remarks on the Work of Sugar
After mild provocation, Marco and Tomeu asked me to publish some of my reactions to sugar's architecture, design, and implementation. Here are a few initial comments. 1) Sugar could better hold contributors if it (and its web presence) were designed to be extended and to highlight external contributions. Evidence: Trac and xmonad both have thriving communities of contributors based around their plugin architectures and community sites like trac-hacks.org. Evidence: Sugar has already attracted new contributors by creating three different extension points: Activities themselves Device entries on the Frame Control Panel Entries Evidence: Non-extensible aspects of Sugar like activity launching, home view layout, frame contents, and the presence service have stagnated. 2) Sugar would run more smoothly on-XO if jhbuild were retired. By running at non-XO speeds, jhbuild permits Sugar developers to retain faulty assumptions about the environment in which their code will run. Evidence: Sugar uses algorithms which casual inspection reveals to be horribly slow and Sugar has, in the past, suffered from easily-revealed memory leaks which went unfixed for long periods of time in part because developers had little personal motivation to fix the issues. 3) Sugar is built on technologies which encourage excessive layering. Excessive layering makes it hard to approach code (high cognitive burden) and harms performance (by causing unnecessary data copying and by causing data to be stored in the heap rather than the stack or in pageable regions of memory. Evidence: the convenience layers of Python wrappers around dbus-python stubs around dbus objects around two layers of python bindings for an information retrieval system built on a filesystem in merely to create and save files with a dict of attached metadata. Evidence: The convenience layers of Python wrappers around gobject properties around dbus-python stubs around dbus objects around a hardcoded network manager around the underlying CLI tools and the kernel's netlink sockets. Evidence: The SVG python icon objects in a three-layer Sugar icon cache spanning gobject properties and cairo surfaces atop gtk and gdk windows atop X windows and pixmaps atop... 4) Sugar's underlying technologies bias it toward computing results more eagerly than is appropriate. Evidence: Python and C are eager languages without well-documented support for lazy computation. Evidence: Sugar performance has been shown to improve by making some computations lazy, e.g. palette creation. 5) Sugar is built on technologies that incentivize its developers to recompute prior results which could be cached across boots. Evidence: Sugar is developed by people running on hardware that is fast enough to recompute results at little cost to interactivity (see §2). Evidence: Also, OLPC's shipping JFFS2 implementation does not support writable mmaps or uncompressed inodes. Evidence: Python lacks support for loading data without unmarshalling it from bytestreams. 6) Sugar was not built with compartmentalization in mind. All its functionality runs with the full privilege of the human operator and it has very coarse process-level memory protection. Evidence: Sugar packs great functionality into a small number of processes and occupies only one uid. Evidence: Sugar's process-level boundaries (e.g. shell, DS, PS, telepathy CMs, rainbow, activities) seem to me to be strongly correlated with the existence of cliques of the developers who built them. 7) Sugar prefers IPC techniques with inferior human interfaces (DBus, X) to IPC techniques with superior human interfaces (HTTP, 9P, environment variables, well-known files, process arguments + status codes + man pages). Regards, Michael P.S. - Let me know if you'd like to see more such remarks in the future (perhaps on other subsystems?) or if you'd like to see more detailed exploration of any of the items noted above. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
Apologies for the immediate self-reply, but Marco pointed out to me that I left out one important piece of context: All of the issues I raise above were selected, in part, because I believe that they are incrementally fixable. Some require adjustments to underlying technologies, some require changes in mindset, etc, but all can be attacked today. Ask for details if you want them, or better, try to supply your own. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Tue, Jul 22, 2008 at 08:01:02PM -0400, Ivan Krstić wrote: On Jul 22, 2008, at 7:49 PM, Michael Stone wrote: Python lacks support for loading data without unmarshalling it from bytestreams. Can you clarify what specifically you mean with this point? I regard fully pythonic python data as a subgraph of a reference-counted object graph. So far as I know, Python has lots of interesting ways to parse bytestreams into object graphs, but no great way to read an object graph directly into memory without the overhead of parsing or to save an subgraph of its object graph directly to a bytestream. This makes it hard to use pythonic data via shared-memory or to pull it quickly off of a filesystem. (An interesting potential hack would be to teach Python how to use multiple object graphs so that one could more easily confine an interesting subgraph to a fixed set of pages.) Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Trac workflow
On Mon, Jul 21, 2008 at 08:35:10AM +0200, Simon Schampijer wrote: We have the 'package' option as well. I guess this is what needs to happen after checking into git. 'package' is then doing the tarball release and 'add to build' building in koji maybe? Packaging is the production of rpms or .xos. Sometimes, people want us to include new RPMs. Other times, when we're in change control, the packages need to be migrated into the release build. The 'add to build' action can be used in these cases. If we do it that detailed we might want to add a 'add to git' tag as well. All code should be in source control all the time, period. No exceptions. (Use branches or separate repositories if you need to keep your work separate from your stable material.) Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] URL and Integration
On Fri, Jul 18, 2008 at 09:31:24PM -0400, Eben Eliason wrote: On the other hand, maybe what we need more is a forum space. You do realize that both forum.laptop.org and the OLPCNews forum have been up and running for months (years?) with thousands of replies? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Display warnings in sugar
On Thu, Jul 17, 2008 at 10:27:21AM -0300, Emiliano Pastorino wrote: Emiliano, I'm not sure of the right way to help you in the long term, but if you want a quick hack, you might try something like: 1. Install a cronjob that runs every few minutes. 2. When it runs, it should check the available space. 3. If it concludes that space is low, pop up a warning. Warnings can be simple X or pygtk programs (see the 'dialog' Linux scripts for ideas). To get this hooked up to the running X display, you'll need to set some environment variables: DISPLAY=:0 XAUTHORITY=/home/olpc/.Xauthority Ask if you need more help. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Wed, Jul 16, 2008 at 09:10:56AM -0400, Greg Smith wrote: Who can gather the consensus and take responsibility for updating the wiki if needed? No one can, yet, because there's a real argument going on between the people who have to live with the versioning scheme on the infrastructure and security side and the people who want to use it in the UI. In particular, there are non-trivial security issues with identifying activities internally with _anything_ spoofable - i.e. with any identifier that an activity can 'claim' without reference to some more primitive sense of identity (e.g. a cryptographic manifest). Consequently, as I have claimed on the several other occasions when this discussion has come up, we are _not_ going to decide on an activity naming and versioning scheme without having written down our use cases and checked that the proposed design satisfies them. What _should_ be happening in this thread is the collection of use cases. For a small selection of the issues involved, please refer to http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1 http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2 Regards, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Wed, Jul 16, 2008 at 01:16:51PM -0400, Greg Smith wrote: *** Salient quotes: Each activity.info file must have a activity_version key. The version is a single positive integer. Larger versions are considered newer. The value assigned to this key should be considered opaque to the activity; the only requirement of the activity is that it must be larger for new activity builds. In my opinion, the information quoted above is correct as of today. All that is true beyond that is that we are designing a revision of the activity packaging guidelines and formats. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] proposed addition to the Activities page templete
On Wed, Jul 16, 2008 at 01:40:50PM -0700, Edward Cherlin wrote: I would like to see all Activities sharable in the sense that others can at least watch what the primary user is doing. insert obligatory comment about remote X + multi-pointer X. (Ask jg for details). Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
I fail to see what makes the XO case different from the rest of the software world - from the pages you link I agree that the pages I cited presuppose that you understand how our requirements differ from those of the rest of the world. Some specific examples: - Our users often can't make informed decisions about what software they should be running. - Our users probably do not have root on their machines, yet still need to perform package-management-like tasks. - In addition to accepting code hierarchically from upstream providers, we want to share code fluidly between XOs. - We want the software we provide to support a higher standard of security (defined in Bitfrost) than other systems strive to provide. - We must attempt to minimize bandwidth usage while moving bits around and must tolerate long networking delays. - We cannot rely on any established public key infrastructure to verify the identities of code providers or the authenticity of the code they are providing. - We expect users will be constantly redistributing modified versions of software that they downloaded to their systems. - We expect that our user groups will, in general, NOT share common languages with one another (or, necessarily, with us). - We expect that many users will be translating their own software. - We MAY NOT assume that users have global connectivity with which to satisfy dependencies, verify claims about information, distribute their work, etc. For these reasons, in my humble opinion, choosing our software packaging format and guidelines (of which version numbering is but a single aspect) is NOT A TRIVIAL EXERCISE and is not as simple as picking an off-the-shelf format. (I wish that the reality were otherwise). Do you require more justification? Regards, Michael ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On Thu, Jul 17, 2008 at 11:15:07AM +1200, Martin Langhoff wrote: On Thu, Jul 17, 2008 at 10:52 AM, Michael Stone [EMAIL PROTECTED] wrote: For these reasons, in my humble opinion, choosing our software packaging format and guidelines (of which version numbering is but a single aspect) is NOT A TRIVIAL EXERCISE and is not as simple as picking an off-the-shelf format. (I wish that the reality were otherwise). I understand the points you make, but - AFAICS - they don't have much bearing on versioning (by which I mean to say: the conventional RPM/Deb versioning scheme works fine). I don't care too much what names people give to activities but I care greatly about how the software that manipulates those activities is written -- in particular, about the way that it makes use of those names, both internally and in the UI. Thus, while I will likely be content with any naming convention that might be proposed, I have serious reservations about the quality of the software that will result from the _procedures_ being used to choose that naming convention. Hence my request that we perform at least basic diligence in checking that the proposed naming scheme and its intended usage in software is consistent with our largely unwritten requirements. They do impact packaging, but... they are not *that* special either. My goal is to avoid deploying short-term hacks which complicate future work. Hacks to conventions seem particularly dangerous to me because they're the hardest things to change if you get them wrong. As I said above, I will be happy if we choose to adopt an existing naming scheme so long as that naming scheme is compatible with our requirements and use cases. We just need to demonstrate that we are aware of the consequences of our proposed scheme by checking that it doesn't paint us into a corner down the road. Do you require more justification? Ah well, I know notink of the XO so back to my cave where I try to reach my goals reinventing the _least_ wheels. We have different resources to bring to bear on our respective tasks. Sorry about the noise. I always (eventually) appreciate your input, even when I argue with you or cut you off too quickly for want of the patience to find out where you're coming from. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
Otherwise how can we reasonable sort/group the activities in any way that makes sense? I suggested one (stupidly slow, but very general) approach based on the Travelling Salesman problem. To recap: Regard all activities as nodes in a fully connected graph. Let activities state that they are close to some collection of other activities according to any system you please. (e.g. specify a metric on activities, plug in some heuristics on names and numbers, give a list of 'similar' activities, do cosine similarity on keyword vectors, etc.) When you learn that A thinks it should be close to B, shorten the edge between A and B. Solve the TSP for the graph. Approximate solutions are fine. Designate a starting point (I suggest a 'Help' activity) and order your activities according to your solution. You can even do fancy grouping tricks for small-diameter subgraphs. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity Backward Compatibility
As I have suggested before, I think that these sorts of checks also matter enourmously to the quality of user experience that we'll be able to provide when we start seriously attempting to provide 'easy code sharing' features. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Sugar] Browse extension/plugin structure
Please speak to me of your thoughts on the security implications of making Browse extensible. Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [OLPC library] Physics -- Newtonian mechanics.. for kids!
That's true, however I think it's also been agreed that... Could you please cite the discussion leading up to the agreement you're referring to? Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [OLPC library] Physics -- Newtonian mechanics.. for kids!
Please remember that activity version numbers must be integers. Software does exist which relies on this assumption! Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [SURVEY] builders, how do you build? what do you build?
On Fri, Jun 27, 2008 at 05:23:44PM -0400, Erik Garrison wrote: 0) Who are you and who do you directly work for? Michael Stone, and Kim Quirk, respectively. 1) What do you build? Typically, rainbow, olpc-utils, puritan, and full OS builds. Occasionally, other things like sugar, X, xulrunner, initscripts, the kernel, and ejabberd. 2) Where does it come from? / Who directly provides you with source code? We can calculate commit statistics for git repositories with logic like: git log | git shortlog -s -n While there are some obvious limitations on what can be inferred from these statistics, they are perhaps helpful for pinpointing the truly guilty parties. Rather than me filling in all the details, I suggest you calculate your own results based on the public repositories on dev.laptop.org. (If you do, please remember to be careful about checking for duplicates.) As release manager, I am provided with source code from pretty much everyone. Socially, I review a lot of software for people like Martin and Scott and I review build changes for anyone who wants to make them. I think I spend most of my integration time talking with Scott, Eben, Marco, Joe, and Greg. 3) Where does the output of your build process go? / Who handles the immediate output of your builds? For packages: into a local directory, then into a webroot on dev.laptop.org, then into the OLPC package dropboxes or Fedora CVS, then into development builds, into release builds, and into manufacturing. For builds: usually into a local directory, onto a USB key, then onto an XO for personal consumption. 4) Where specifically is it built? (I want server names and/or descriptions, where security is a concern please share them with me privately.) teach, pilgrim, xs-dev, and koji.fedoraproject.org. 5) What build systems do you use to build software? Please briefly describe their operation or provide a link to documentation or source code which does. I've already written extensively about the software that I use on our wiki. Check out http://wiki.laptop.org/go/Build_system and http://wiki.laptop.org/go/Developer/Fedora Also, the Python and GNUmake manuals. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Making updating easier
I've been thikning about update issues a bit and was wondering if we have plans/processes in place to handle maintaince of multiple releases? My perception of our basic purpose is that we're in the business of creating reference OSes which can be modified with OLPC support at fixed points of extension (activities, keyboard settings, etc.; Peru) or which can be used for inspiration to create more customized (but less OLPC-supported) works (Uruguay, Nepal). In the latter case, our expectation is that people who customize our examples will periodically meet with us to exchange mergeable material. We also hope that they will, from time to time, rebase their changes onto our newer reference OSes. If one accepts this statement of basic purpose, then it follows for me that our basic responsibility is to create, document, and train people in infrastructure, packaging, build creation, issue/request-tracking, and release processes which facilitate parallel work on each of the streams of development that have active audiences. Recent examples of our response to this proposed responsibility include * the creation of the USB-based fixed-extension customization technology, * Scott's image-builder for producing disk images from customization keys; i.e. for making local releases from reference OSes, * our mutual formulation of -build, -devel, -testing, and -updates Koji tags for the construction and maintenance of the package-sets associated with releases. * the work that went in giving, recording, and publishing Scott's mini-conference our present series of tech talks * time spent working with Emiliano Pastorino of Uruguay on incorporating knowledge and technology from Uruguay's customizations of the 640-656 series builds into our own. However, as you rightly remind us, there is a fundamental question which is not addressed by any of the work described above: what support, if any, does OLPC offer for its reference OS releases? Is the support bounded below by some stronger basic responsibility? Is it bounded above by some limit on the temporal extent of the support? I don't have any idea what the real answers to those questions might be. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] feature freeze coming
On Sat, Jun 21, 2008 at 10:16:45AM +0200, Tomeu Vizoso wrote: Which are the freeze dates for the OLPC August release? There may be still time for getting olpc-netutils in. olpc-netutils changes are fairly low risk because not much depends on its behavior and because it doesn't conflict much. Consequently, if resources permit, we should be willing to accept changes to it much later than for something central to the system. As for dates - Marco requested some from me a couple of days ago and I told him that I'd work on it once Fudcon was over. If you still need to, please ask again mid-week. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] feature freeze coming
On Sat, Jun 21, 2008 at 01:54:07AM +0100, Giannis Galanis wrote: What is the decision on olpc-netutils? It involves #7171, #7172, #7174 Somebody needs to package them, no one has volunteered, and I haven't gotten to it yet myself. Nothing more, nothing less. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add an option for choosing the layout in the favorites view.
On Fri, Jun 20, 2008 at 06:27:33PM +0200, Marco Pesenti Gritti wrote: On Fri, Jun 20, 2008 at 6:24 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Fri, Jun 20, 2008 at 6:08 PM, Walter Bender [EMAIL PROTECTED] wrote: Is this done in a way such that it can be set by the customization key process? I can imagine that many groups will prefer the ring to random and want to make it an installation default. Not right now, but would be quite easy to add an option to the control panel and let customization keys change the stored preference. Even if not exposed in the cp UI we should at least have an hidden preference. We have no way right to customize sugar profiles but we should have one. Marco I'm interested by the (implicit) idea that (all?) settings modifiable through the control panel should also be customizable. However, as I pointed out not long ago, some care needs to be taken to restrict the ability of the customization process to violate our security principles. As a strawman, how about using a convention or technology similar to http://thedjbway.org/daemontools/envdir.html to record the key-value settings that make up the bulk of the 'customizable' features? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Browse autocompletion
On Fri, Jun 13, 2008 at 01:37:33PM +0200, Tomeu Vizoso wrote: +cur = self._con.cursor() ... +cur.close() Should we use try...finally blocks so we don't leak open cursors? Also, we could use the with statement from future. The with statement (and the contextlib's @contextmanager decorator) have worked out really well for me so far. I'd be happy to see it used more widely throughout Sugar. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Release Status Report - 8.2.0
I promised regular status reports on our release work and I've been lax in writing them. Here are my current thoughts on the content of and risks associated with our second (August) 2008 release, 8.2.0. These assesments are heavily based on current rates of improvement and available labor. (I'm seriously concerned about upcoming distractions, but don't quite know how to factor them in.) Current Thoughts: * I'm EXPECTING major changes in: a) Sugar frame/home-view rework - Marco b) Sugar control panel- Simon c) Browser improvements - Simon/Tomeu d) F-9 Rebase - Dennis/Michael e) Manually enabled power management- Chris/Scott/Deepak f) Presence collaboration reliability bugfixing - Collabora, Morgan g) Backup to XS * I'm NOT EXPECTING major changes in the Journal the Datastore activity isolation (modulo faster launching) the neighborhood view * I'm UNCERTAIN about what architectural changes will be available for consideration in: collaboration (e.g. gadget, cerebro, telepathy-cerebro). - Collabora, Polychronis theft deterrence - Scott, Emiliano software provisioning (e.g. olpc-update / reflash) - Scott, Mitch wireless/connectivity - Michailis, Cozybit, Deepak I'm also UNCERTAIN about several CONFIGURATION DEFAULTS like: touchpad in absolute or relative mode? hot-corners delay? activity placement algorithm / view invalid browser certificate handling algorithm Next steps: If you're working on something where I'm expecting major change, then we should discuss moving your changes from development into an official test build for QA in the next week. I suggest contacting me by public email with your first proposal. Documentation in Trac bugs or wiki pages will be happily accepted. (If you think I've misjudged an changeset, please reply so that we can fix the issue.) Open Questions: * You want to make changes to the release candidates. What is your burden of proof (of quality/readiness) today? What will it be N weeks from now? * We managed to ship the Ship.1? release only after we agreed on the WE ARE DONE WHEN: ... list. What are the contents of the release checklist this time around? (Need to figure out how to involve the deployment tech leads... in answering this). Thanks, Michael P.S. - Ancillary documentation: Release Process: http://wiki.laptop.org/go/Plan_of_Record-2008 Priorities: http://wiki.laptop.org/go/Priorities-2008 Stub 8.1.1 Features: http://wiki.laptop.org/go/OLPC_8.1.1_Features (needs to be finished so we can write http://wiki.laptop.org/go/OLPC_8.2.0_Features for the QA dept). ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Home Design: Free Layout View
Two general comments: First, I really like the idea of a design dimension that I see latent in your work. Zoomable interfaces should zoom in more than one direction. Second, independent of whether we adopt your exact proposal, we can and should think about providing subtle configuration ability for things like views. For example, we could rule that the right-most view is the default one and allow them to be reordered by dragging. Alternately, we could position a small arrow or outline beneath the default one and allow the arrow/outline to be moved. Comments? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
On Wed, Jun 11, 2008 at 10:58:54AM +0200, Bert Freudenberg wrote: Isn't resume with an oxymoron? Yes. I refer you to the grammar discussion we had a few weeks ago: http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2#Grammar_and_Criticism (also see the diagram at the top of http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1 ) Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
On Wed, Jun 11, 2008 at 11:37:13AM -0400, Benjamin M. Schwartz wrote: Cute. Incidental thought: is performing a translation an action? (If so, then when new versions of the source objects become available, it might be straightforward to replay the action on the new version of the sources.) Secondary thought: if translating is an action, then have we simply produced transient or instantaneous activities which have no GUI? To me, the interesting claim is that these transient activities (or translators, if you think they're different) should be able to advertise that they can turn types A into (potentially) B, C, and D.) (If we expect the activities to be able to read the user's data in order to state make this determination, then we have even greater incentive to implement the Bitfrost P_DOCUMENT_RO and P_NETWORK protections - they seem to be ideally suited to this use case.) (Jill: But Jack, what about Translators that require network access to function? Jack: I'm so glad you asked, Jill! In fact, ...) Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] not preserving journal
On Tue, Jun 10, 2008 at 11:06:37AM +0200, Tomeu Vizoso wrote: On Sat, Jun 7, 2008 at 10:06 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Yes, we have several tickets about these issues, but nobody to work on them :/ Please cite ticket numbers. Anyway, note that most of the final users will have backups of their journal before updating, Huh? How are they going to have backups? Did someone release backup software without my noticing? Or are you simply betting that it will get done soon? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal object transfer for 8.2
Tomeu, have heard occasional requests to implement the sending and sharing of journal entries. It's a desirable feature but, from my perspective, it's much lower in immediate priority than work which brings the sugar UI revision into a releasable condition and which polish the existing work by closing several of the 379 tickets assigned to component 'sugar': http://dev.laptop.org/query?status=assignedstatus=newstatus=reopenedcomponent=sugarorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=component So the questions are: is this a feature we should deliver for the 8.2 release? In my opinion, no. Do you think differently? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal object transfer for 8.2
On Mon, Jun 09, 2008 at 04:18:10PM -0400, Walter Bender wrote: I would argue otherwise. Since Sugar has no control over the robustness of the network, having some way of sharing at a basic level from the Journal is seemingly a high priority. My feeling is that since Sugar has no control over the robustness of the network, the feature will function poorly, if at all. Consequently, I would rather see bug-fixes which will bring the system closer to its intended operation with high probability. However, this is just a personal preference. I'm (mostly) happy to release whatever you send my way, so long as it fixes more problems than it creates. Half of the high-priority bugs in the link you provide are in fact not really Sugar bugs, but subsystem bugs. The others don't seem to be particularly pressing. Perhaps a few hours of triage are called for? Here are a few of my favorites: http://dev.laptop.org/ticket/7011 --- Zoom buttons should cycle http://dev.laptop.org/ticket/7220 --- Populate activity ring http://dev.laptop.org/ticket/4236 --- Cancel activity startup http://dev.laptop.org/ticket/7020 --- Force activity shutdown http://dev.laptop.org/ticket/6895 --- Access point UI http://dev.laptop.org/ticket/6909 http://dev.laptop.org/ticket/5444 --- Robustness to failure http://dev.laptop.org/ticket/6148 --- Non-ASCII Activity Names http://dev.laptop.org/ticket/6471 --- Activity startup times http://dev.laptop.org/ticket/6472 http://dev.laptop.org/ticket/6237 --- Cloaked APs http://dev.laptop.org/ticket/6281 --- 802.1x for NY,UY! http://dev.laptop.org/ticket/4877 --- Session API Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: * Browser bookmarks and autocompletion. - priority 3 I'd really like to see some progress on #542/#5534 (deal with non-standard SSL certificate authorities). This is going to become a bigger and bigger stumbling block the longer we wait. Surely we could manage some sort of 'accept this cert' button? (Keep in mind the possibility of another G1G1 coming our way in the foreseeable future.) Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release process
Folks, Here's what I took away from the comments I received concerning my transcript of my conversation with Marco and a few thoughts in response. You should check my summary to see if I misunderstood you. Regards, Michael Summary --- Dennis: To date, to our detriment, we have done development and stable releases from the same tree. We should be more like Fedora. Fedora does development in rawhide. Periodically, it forks 'stable' and 'updates' branch-pairs off of rawhide. Yum is handy for testing updates and new changes. Scott: Stable builds are good, but development is necessary. Development requires distributing some incomplete/busted code. Use topic branches freely, but merge code when necessary to get broad testing. It sounds like F9 is ready for broader development. Debian's three-stage change filtration process has worked well for them. Debian's release management involves combing the bug database for regressions and minor bugs found in testing which were discovered after the 14-day grace period from unstable and which haven't already been fixed, documenting known 'wont-fix' and 'relnote' issues, and testing upgrades and installation. Kim: I support change filtration and associate teams with branches: Support with stable, QA/Test with testing, and Dev. with unstable topics. The release manager chooses things to move from dev. into testing. However, they need agreed-on 'readiness criteria'. Also, we should identify must-have changes up front. Tomeu, replying to Kim: Whose job would be to make sure that people are working on things that have the highest probability of getting into the next release? The project manager? If so, I guess we can expect some tensions between the release and the project manager. If it's the same person (or set of persons), we could face another update.1. Morgan, replying to Tomeu: I see the project/product manager as the person fighting to get a certain feature set into the release, and the release manager being the one who tries to keep unnecessary changes out of the release (for stability reasons, or to meet the deadline). Claims -- I. There is no excuse for breaking centralized build streams that others depend on when one-off 'topic builds' and dedicated build streams are available. Please shout loudly whenever you could use a topic build or build stream. They're very easy to make and if large demand exists, it's straightforward to build better tool support. II. Dennis is right that we should maintain separate 'base' and 'updates' branches for each release. However, unlike Fedora, it is only sometimes helpful for us to fork a release off of a development branch. Other times we wish to make an incremental release. III. It's better for people to manually maintain build-streams (and forks of other people's build streams) because it promotes the maintenance of knowledge of bug status and priority in the maintainers' heads. If the maintainers communicate primarily through archived media, then everyone wins because we have both the archived records _and_ fresh, reliable human knowledge with which to make decisions. IV. If we get bigger, then this will cease to scale and we would be well advised to adapt something like the Debian automated filtration process. However, at our present scale, I think I can get us better results by personally negotiating each block of changes. Consequently, with Dennis' help, I'm maintaining build streams for the 8.1.1 release (this week) and soon, for the 8.2 (August) release. If you've made or intend to make changes since 703 and haven't yet done so, you need to come talk to me about how to we're going to release them! Other Thoughts -- V. Freeform change filtration seems to rely on large quantities of independent changes and on larger quantities of test effort for filtering those changes. At the moment, we seem to have neither large quantities of change nor large quantities of available test effort. VI. We receive a fair amount of software which we don't wish to include in our releases but which we still want to make available for easy installation by end users. Package management is a good way to provide this software. Consequently, our package branches should contain more software than we put into our builds. VII. There are several important members of our community who refuse to have anything to do with the Fedora community and the Fedora packaging process. Justified or not, these members' adamant boycott of the Fedora processes and community appears to me to foreclose the possibility of a purely Fedora-based workflow. This substantially increases the cost of any arrangement we might make because it leaves OLPC responsible for maintaining server infrastructure which could profitably be left to Fedora. (It also, dramatically increases the time that both Dennis and I have to spend manipulating your patches/packages. Do us both a
Re: [sugar] [PATCH] Avoid duplicates in the bundle registry
On Wed, May 28, 2008 at 10:46:45AM +0200, Tomeu Vizoso wrote: On Tue, May 27, 2008 at 6:44 PM, Michael Stone [EMAIL PROTECTED] wrote: On Tue, May 27, 2008 at 09:15:39AM +0200, Tomeu Vizoso wrote: +for bundle in self._bundles: +if new_bundle.get_bundle_id() == bundle.get_bundle_id(): Why are we performing repeated linear search instead of storing bundles in a datastructure with sub-linear containment lookups (e.g. a set or a hashtable)? Because the patch is simpler this way. Why do you think that using a set or a table might be better here? Because my algorithm (store a dict mapping bundle id to biggest version yet seen) makes the same decisions yours does with one hash table lookup instead of O(n) string comparisons? NB: naive implementations (i.e. where you decide to create both the list and the dict) will have creation and maintenance costs in space and time which could exceed the benefit gained by from cheaper lookups. I haven't studied the code in enough detail to see what the most appropriate data structures are. Question: does our implementation ever pay attention to the order of the entries in self._bundles? Why exclude old bundle versions? Eben's new design makes very clear that several versions of the same bundle need to be installed and the user can manage them as wanted. When I started implementing this some months ago, I found some problems with identifying bundles other than by its bundle_id. See: http://lists.laptop.org/pipermail/sugar/2008-April/004893.html I even proposed some patches that partially address this: http://lists.laptop.org/pipermail/sugar/2008-April/004894.html http://lists.laptop.org/pipermail/sugar/2008-April/004895.html http://lists.laptop.org/pipermail/sugar/2008-April/004896.html Those patches were not reviewed because it was considered better to wait for the discussion about bundle identification to be settled. Heh. Fair enough. Have you reviewed any of the bundle commentaries that Eben, Jameson, and I have been writing? http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1 http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2 Haven't had time to fully read. Can someone summarize the conclusion? I'll see if I can come up with something for you. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release process
On Wed, May 28, 2008 at 11:44:07AM +0200, Marco Pesenti Gritti wrote: On Wed, May 28, 2008 at 8:00 AM, Michael Stone [EMAIL PROTECTED] wrote: Claims -- I. There is no excuse for breaking centralized build streams that others depend on when one-off 'topic builds' and dedicated build streams are available. Please shout loudly whenever you could use a topic build or build stream. They're very easy to make and if large demand exists, it's straightforward to build better tool support. I'm not sure to understand what you mean exactly here. Are we going to keep both a centralized unstable build (joyride) *and* decentralized topic builds? My experience over the last few months has been that a centralized unstable build stream is worth less than it costs to maintain using the tools we've built today because it tends to aggregate changes of widely varying quality without recording which changes are good and which are bad. I now think that we are better served either by relying wholly on decentralized topic builds for unstable development, on unstable build streams under the manual control of individuals and teams, or on an automated unstable streams only if they automatically quarantine breakage. (If other people have found it to be a worthwhile tool, they are certainly free to continue using it provided that they're willing to take over some maintenance responsibility for the systems that implement it. I simply have no desire to rely on it myself.) IV. If we get bigger, then this will cease to scale and we would be well advised to adapt something like the Debian automated filtration process. However, at our present scale, I think I can get us better results by personally negotiating each block of changes. Consequently, with Dennis' help, I'm maintaining build streams for the 8.1.1 release (this week) and soon, for the 8.2 (August) release. If you've made or intend to make changes since 703 and haven't yet done so, you need to come talk to me about how to we're going to release them! Which build branch requires your approval and which doesn't? Only the ones that I'm maintaining. I'm fine with personal negotiation, but we need to document how maintainers are supposed to negotiate inclusion in the builds and through which tools it concretely happens. Fair enough. I'll propose a first draft: 1. Contact me on devel@ or in the public IRC channels when you want to negotiate. I'll either tell you that I'm busy or I'll talk with you. You should be prepared to explain what your changes do and why you think they're good. 2. After we talk, we'll each have a better idea of how things will proceed, e.g. * when you'll have packages ready for me to try out, * what bugs I should try to test carefully, * what areas I need to watch for regressions, * and what other work I might be doing that you could help with so that I can get to your changes sooner. 3. These issues are complex and they change over time so we'll need to talk regularly in order to apprise one another of status changes and to make up answers to questions that we couldn't answer during the previous conversation. 4. We should record the results of these conversations for future reference, presumably on the wiki or in Trac. I have a mild preference for the wiki because I think we're going to want to edit intermediate drafts of these plans but I can be easily persuaded toward other systems. The stub at http://wiki.laptop.org/go/User:Mstone/Release_queue suggests one way to begin. Comments? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Software Status Meeting Tomorrow @ 1400 EDT, 1800 UTC in #olpc-meeting on freenode
On Wed, May 28, 2008 at 10:15:07AM +0200, Tomeu Vizoso wrote: Hi, the sugar team built a new rpm to be included in the 8.1.1 release, see: http://lists.laptop.org/pipermail/sugar/2008-May/005935.html Should I enter a ticket or something? Don't bother; this reminder email is fine - I'll see what I can do. Is anyone from the Sugar team able to help out with testing this week? Michael P.S. - In the future, please ping me directly if you write threads like the one you cited and I haven't replied to them within, say, two days. I apologize that this one escaped my notice since I remember requesting a block of changes like this one from you around when this thread was written. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Software Status Meeting Tomorrow @ 1400 EDT, 1800 UTC in #olpc-meeting on freenode
On Wed, May 28, 2008 at 03:02:17PM +0200, Marco Pesenti Gritti wrote: Relying on email and irc for this seems fragile to me. If a trac query would reveal the packages which are staged for inclusion in a certain release, it would be pretty much impossible that they go unnoticed. Marco That's fair. Suppose we make tickets for each release contract. The relevant properties of the contracts that we want to represent include their risk of slippage, the people who are responsible for seeing them to fruition, and some material about the terms of the contract like links to test cases, test results, and which bugs/features are supposed to be finished upon successful completion of the contract. Some of these things are easy to represent with existing Trac features. For example, we might represent slippage risk with a simple tag scheme like rel:+, rel:?, and rel:- Example interpretation: If we saw a ticket labeled rel-8.1.1:- rel-8.2:? then we should conclude that this was a contract which had slipped from 8.1.1 to 8.2 and which was in question in 8.2. (The advantage of this scheme over regular milestones is that my example ticket would be represented in proper context in displays about either 8.1.1 or 8.2). We also need some way of recording what actual people are responsible for bringing the contract to fruition. Trac only permits one Owner but it permits many tags. It seems that tags like role:name (e.g. tester:erikos) would suffice for this purpose. What to do about test cases and test results? Perhaps we should establish a convention that all release contracts will have a test cases wiki page and a test results wiki page at specific names, e.g. wiki.laptop.org/go/Test Cases/num wiki.laptop.org/go/Test Results/num and modify Trac to automatically insert prominent hyperlinks on tickets tagged rel-contract? Finally, there is the issue of work queues. I still have no clue how to represent, using either either Trac or the wiki, the fact that every individual has a work queue which differs from the Global Ticket Priority ordering. People clearly have personal queues for all sorts of reasons including: * people process several tickets concurrently to avoid waiting on one another * individuals often prefer to fix easy, hard, or well-understood things first * people barter work among themselves in order to help one another finish things off; this causes people to work on surprising things (I want to know about personal queues because I want to pay attention to the instantaneous velocity of development [i.e. in order to predict where the code base will have moved to after the next \epsilon units of time have elapsed].) Comments? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release process
On Wed, May 28, 2008 at 02:54:24PM +0200, Marco Pesenti Gritti wrote: On Wed, May 28, 2008 at 2:03 PM, Michael Stone [EMAIL PROTECTED] wrote: My experience over the last few months has been that a centralized unstable build stream is worth less than it costs to maintain using the tools we've built today because it tends to aggregate changes of widely varying quality without recording which changes are good and which are bad. I now think that we are better served either by relying wholly on decentralized topic builds for unstable development, We will try to find time at linuxtag to experiment with these for Sugar. Awesome. Let me know if you get stuck as I can probably unstick you. on unstable build streams under the manual control of individuals and teams, How is this different then joyride? Are these topic streams? As Scott said, Joyride is somewhere between an unstable build stream and a testing build stream. It's also under automated control insofar as it automatically pulls in changes made by anyone with commit access to the dist-olpc2 koji branch and to the joyride dropboxes on dev. I think of topic streams as being things like Dennis' F-9 branch, my rainbow branch, Bernie's X branch, etc. (One could plausibly argue that Joyride is a topic branch for the Sugar UI redesign - do you think this is true?) or on an automated unstable streams only if they automatically quarantine breakage. Can you elaborate on how breakage would be quarantined? How difficult it will be to build infrastructure for it? Do we have time to do it for August? The basic idea is to give your build system enough information to automatically revert packages that look buggy. Debian does this by teaching their build system to talk to their bug tracker and by teaching their bug tracker how Debian packages work. A second approach is based on using buildbot/tinderbox continuous integration testing with automated test suites to qualify or disqualify changes. Both approaches give your build system enough information to rapidly revert packages that look buggy; however, both systems continue to suffer from the garbage in, garbage out problem. Consequently, I think that we are better served by manually improving the quality of the build stream inputs by encouraging people to do individual testing builds (or just to publish packages for review on top of an existing build) before pushing their changes into a shared build stream for wider review. (Think of this as the kernel maintainership model where changes originate small and private, then manually 'bubble up' in into wider and wider testing.) Which build branch requires your approval and which doesn't? Only the ones that I'm maintaining. And you maintain the stable builds for 8.1.1 and 8.2.0, correct? Correct. I'm fine with personal negotiation, but we need to document how maintainers are supposed to negotiate inclusion in the builds and through which tools it concretely happens. Fair enough. I'll propose a first draft: 1. Contact me on devel@ or in the public IRC channels when you want to negotiate. I'll either tell you that I'm busy or I'll talk with you. You should be prepared to explain what your changes do and why you think they're good. 2. After we talk, we'll each have a better idea of how things will proceed, e.g. * when you'll have packages ready for me to try out, We need to tell people how they should build these packages and how to let you try them out (provide a custom build, get them in one of the unstable streams, just provide one or more rpms to install on the base of the current stable build...). It's going to vary from task to task. For small things, I'm perfectly happy receiving nothing more than a package to try out. For something big like the Sugar UI redesign, I'm going to need something a bit more systematic. Maybe we could settle make a list of example changes and the packaging events through which they were qualified? e.g.: Keyboard - reviewed patches, then Koji-built packages tested by the submitter (Sayamindu), then test builds made by Dennis olpc-configure - Koji-built packages placed in joyride for several weeks, Touchpad - patches, then an installation script to devel, then packages for joyride by the release manager, then inclusion in test builds along with a list of fixed bugs Wireless - several revisions of the wireless firmware with manual smoke testing by the submitter, and several kernel patches to the stable kernel, a kernel build by the release manager, inclusion in a testing build by Dennis, then more serious independent network testing this week * what bugs I should try to test carefully, * what areas I need
Re: [sugar] [PATCH] Avoid duplicates in the bundle registry
On Tue, May 27, 2008 at 09:15:39AM +0200, Tomeu Vizoso wrote: +for bundle in self._bundles: +if new_bundle.get_bundle_id() == bundle.get_bundle_id(): Why are we performing repeated linear search instead of storing bundles in a datastructure with sub-linear containment lookups (e.g. a set or a hashtable)? +if new_bundle.get_activity_version() = bundle.get_activity_version(): Why exclude old bundle versions? Have you reviewed any of the bundle commentaries that Eben, Jameson, and I have been writing? http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1 http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2 Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Software Status Meeting Tomorrow @ 1400 EDT, 1800 UTC in #olpc-meeting on freenode
Let's talk tomorrow about #7014, build 706 (which everyone ought to test; olpc-update -f update.1-706), and what we should take away from the fact that Blake and Ricardo were the only people who contributed patches/packages for inclusion in our bugfix release. Please reply to this mail with any other subjects that you would like us to discuss. I'll see if we can fit them in. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Refactor invites for 1-1 Chat (#6298)
On Fri, May 23, 2008 at 05:12:29PM +0200, Morgan Collett wrote: I will get this patch up in my git repo, as soon as I can figure out why it won't allow me to push (non-fast forward). Git is warning you about divergence: there are patches on the branch you're pushing into that you have not yet 'seen' since they aren't in the history of the branch you're pushing. If you know what you're doing, you can force the push with the '-f' flag. If you screw up, check the reflogs in .git/logs/refs/heads/branch in the remote repo. (The .git might be absent if it's a bare repo). If you want to see the patches that you're missing, run git remote update gitk --all and look for remote branches. Finally, to incorporate the changes, you can merge or rebase. Let me know if more detail is required, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Second Bundle Commentary
Dear sugar, Jameson, Ben, Eben, and I talked at length three weeks ago about bundle formats and the Sugar UI's data model. I've published a barely-edited transcript of that conversation at http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2 Please review it at your leisure both for accuracy and to generate new comments. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] A Conversation with Marco
Marco and I (as well as Dennis and Bernie) had some long chats at the beginning of this week about how to work together to pull of the next release. At Marco's request, I've posted one important chunk of this conversation at http://wiki.laptop.org/go/User:Mstone/Commentaries/Releases_2 Please comment freely. Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] OLPC priorities for Sugar in the August release
Is the solution currently in joyride satisfactory for the August release? Personally I think it's OK. It won't hurt to try to do better if we have time obviously... Let me clarify. I think activities launch is OK. Stuff like frame responsiveness and activity switch should be improved. There are a handful of rainbow bugs that need to be fixed before we should actually ship the thing (specifically #6989), but I'm not aware of other major risks there. I still don't really have enough information about whether the incompatibilities in spool format that I mentioned before warrant bumping the spool-format version identifier from 1-2 (which would require a minor change to the DS). Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 65-node simple mesh test (and counting... ;-)
On Fri, May 09, 2008 at 03:29:51AM -0400, Polychronis Ypodimatopoulos wrote: Data Questions: * Are the measurements used to make the display of 'distributions of profile arrival rate vs. time' produced from timestamps of profile arrival as recorded by all the laptops or by some smaller set of 'sentinels'? * What was the general nature of the connectivity graph of the 65 laptops? Did it change over time? * Did you take any measurements of background network traffic? * Do you have any new insight into how the presence of NM (or of software on top of it that depended on it) was killing your interfaces? At any rate, thanks for this good work! Michael P.S. - When you produce measurements like these, please include links to the raw data. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Broken Touchpads, MouseKeys, and xkb-ctrls-mk_max_speed.
Dear devel@, We can use Xkb/AccessX's MouseKeys accessibility feature to provide an easy work-around for many of our touchpad problems. MouseKeys is easy to enable through xmodmap where, (on a handy B4), you do something like: xmodmap -pke old_map xmodmap -e 'keycode 133 = Num_Lock Pointer_EnableKeys' xmodmap -e 'keycode 111 = Up KP_Up' xmodmap -e 'keycode 116 = Down KP_Down' xmodmap -e 'keycode 113 = Left KP_Left' xmodmap -e 'keycode 114 = Right KP_Right' xmodmap -e 'keycode 36 = Return KP_Begin' Your keycodes may vary; I figured out the right ones by using xev and pressing the appropriate buttons. I figured out the keysyms mainly by reading the xmodmap -pke output. (The Wiki scan codes diagram [1] and table [2] were not accurate for my machine according to xev.) [1]: http://wiki.laptop.org/go/OLPC_Keyboard_layouts [2]: http://wiki.laptop.org/go/Scan_code_table At any rate, after you perform this remapping, MouseKeys can be turned on by pressing 'Shift-LeftGrabby' and can be used by holding Shift and pressing arrow keys (or Shift-Enter to click). All this works great except for the fact that the resulting mouse motion is very slow (being capped at 30 px/sec in the default MouseKeys configuration.) To address this, I wrote a small 'mkspeed' which is available in source form at http://dev.laptop.org/git/users/mstone/mkspeed The relevant code is http://dev.laptop.org/git?p=users/mstone/mkspeed;a=blob;f=mkspeed.c;hb=HEAD Unfortunately, it doesn't work and I can't tell why. (This is my first Xkb program.) Consequently, help would be greatly appreciated. If you're interested, reference documentation is available [3]; see sections 4.5, 4.6, and 16.3.5 for the important details. [3]: http://www.xfree86.org/current/XKBproto.pdf Alternately, if mkspeed proves to be difficult to complete, we can probably just raise the default speed limit in the Xkb implementation in the X server. Michael P.S. - If you know some nice Xkb folks who might like to help out, feel free to forward this email to them. Or tell me why I'm an idiot and why this is a terrible way to work around the jumpy touchpad bugs. P.P.S. - Eben - you might start thinking about how we should actually be exposing this sort of feature in the UI. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] An experience report with joyride-1916
Dear sugar@, I played with some of your recent work in joyride-1916 for a few hours yesterday and I took notes on things which surprised or bothered me. Here they are, in no particular order: * I had a Browse-87 in /home/olpc/Activities and Browse-86 in /usr/share/activities. (I installed Browse-87 by manually unzipping it, then restarting Sugar). I starred Browse-87 and attempted to launch it. Browse-86 was launched. * It takes a _very_ long time to populate the list view. Feedback is needed. (In particular, why can't we draw items incrementally as we discover them?) [This confused Carla when I showed her the new UI.] * It's hard to figure out that you need to visit the list view in order to populate the ring view. I have a couple of suggestions on how to deal with this. a) If no activities have been starred, display a graphic indicating that starring activities will put them in the ring and give a big, prominent button that takes you to the list view. b) If no activities have been starred, include an icon for a tutorial activity which, among other things, teaches you how to star more activities. c) Pressing the home zoom key (i.e. the circle with a single dot) multiple times should cycle through the ring and list views. (And maybe the Journal as well? The Journal is much more shell-like than activity like at this point.) * Activity icons stop pulsing _long_ before a window is mapped onto the screen. This is a big problem. Eben has proposed one method for solving it; however, there's not nearly enough visual feedback connecting the pulsing icon in the corner with the icon I've clicked. I really think that visually representing the queue of activities being launched and visually moving the icon of the activity being launched into that queue would be a good idea independent of big pulsing activity splash screens. * Stopping one activity from the home view should not cause another activity window to be foregrounded. * We should use the stop-sign icon for both stopping activities and for disconnecting from the mesh. [Carla's suggestion] * On my XO, presence became very unhappy as a result of #6586. Dear kernel/firmware people: this badly needs to be fixed. Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 01:42:04PM -0400, Paul Fox wrote: in the time i'd have otherwise wasted is free department, is there currently (or planned) a mechanism to always launch designated activities (either fixed choices, or choices based on recent journal entries) at startup? Personally, I have found extensible autostart mechanisms which process third-party data to be more useful to trojan authors than to users so I'm mildly inclined to consider such mechanisms to be a misfeatures rather than features. Based on this assessment, my direct answer to your question is simply no, such a feature is not currently planned. That being said, I'm quite interested in the tradeoff that you raise between finishing boot quickly so that the user can start doing what they want to do and extending boot with expensive precomputations so that (on average), the user gets to perform individual actions more quickly. Also, where does hibernation fit in your taxonomy? Regards, Michael P.S. - Thanks for writing! ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 07:58:06PM +0200, Marco Pesenti Gritti wrote: On Tue, Apr 29, 2008 at 7:53 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: In a perfect world, you would be right. But that doesn't seem to be the world we are living in, because so many apps seem to need a banner while they launch (openoffice, gimp, banshee, etc.). I'm not 100% sure that we need such a strong feedback during launching, but just saying that we'll make everything fast enough and slow activities won't bite us is a bit courageous, at least. While perfect may be the enemy of good, I do not believe that the present state of mediocrity is either inevitable or good enough. However, I'm not presently submitting patches, so what do I know? * It reinforces the zoom metaphor. Perhaps the implementation will convince me. Luckily for you, I'm not the UI designer. :) * It deals with the problem of children clicking on 2-3 activities at the same time, which proved to be a real issue in the field (will faster activities address this? not sure). If you actually want to rate limit activity startup - why not just rate limit activity startup, perhaps with a cooldown effect? Instead, if you want to make it clear that people should be using one activity at a time, why not queue up launch requests and allow cancellation of all items in the queue? I'm still worried that the feedback might be too strong and unfortunately it's something hard to test until we have activity starting in 1.5 for real. If we had an acceptable form of feedback in the current builds I'd propose to first make activities faster and then play with feedback. Unfortunately, after the redesign, I don't think that's the case. Write yourself a trivial activity that starts xterm and see how long it takes to run. (I used the gtk hello world entries, way back when.) Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 02:54:15PM -0400, Paul Fox wrote: michael wrote: Depends. Any software you run can write to your .xsession, yes? Afterward, will you really notice an extra instance of 'bash', or 'kdmgd', or some other nonsense running in the background, capturing all your keystrokes, aliasing 'sudo', running 'xauth ++', setting up a spambot, or querying an IRC server for recent local root exploits? eek! time to retire. ;-) your point is well taken, but since any program i run manually can also write to lots and lots of things that i run, or use as config, On an XO running a recent build (including 703), almost all activities are prevented from writing to interesting places like .xsession. We just invent new uids and gids (user ids and group ids) for them on demand. Also, there's plenty left to do to help control the current exceptions. i'm not sure why autostart makes a huge difference. Avoiding autostart means that reboot is much more powerful - rebooting will actually have some chance of restoring your system to a workable state. It also gives you a small mischief diagnosis tool - you can do controlled experiments to determine whether your system does annoying things when you run specific activities. (We're thinking of trying to add some power usage monitoring and some network isolation that will further support this use.) Combined with a button or option on each activity that lets one wipe away cached state, this system will plausibly have achieved a new plateau of mischief resilience. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
Can calls to self._mixer or self._master fail even when these attributes are not None? Also, what happens if an exception is thrown by, say, Device.__init__()? Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #6753 Activities should be able to specify mime_types = */*
What sort of activity can handle */*? Can you think of any nasty things that activities might be able to do by advertising suppport for '*/*'? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Mon, Apr 28, 2008 at 10:26:21PM +0100, Martin Dengler wrote: On Mon, Apr 28, 2008 at 01:08:04PM -0400, Michael Stone wrote: Can calls to self._mixer or self._master fail even when these attributes are not None? It doesn't appear a concern from the existing hardwaremanager.py code, and not in practice: I've tested checking/changing the volume in a few activities. I seem to recall having encountered situations where sugar startup would fail (in early versions of the QEMU image, before sound began working) as a result of unchecked use of sound hardware. I fixed the problem by commenting out volume control in the sugar shell. It was a particularly annoying problem because it was persistent, which meant that X entered an infinite reboot loop. The original author of the hardwaremanager.py trusted the gst classes just as much as I am... also keep in mind that I actually saw and worked around two failures (#6933, #6934) of exactly these attributes/implementations, In your opinion, did the original author of hardwaremanager.py (or authors of the clients of hardwaremanager.py?) exercise the degree of caution necessary to deliver a solid, reliable Sugar experience to our present audience? (I say present audience because I think that our audience has changed from one which consisted primarily of developers to one which consists primarily of semi-literate children.) Also, what happens if an exception is thrown by, say, Device.__init__()? Given the current state of error checking, sugar (the shell) will fail to start and matchbox will exit (I saw this during testing, and just now tried 'raise Exception(we love m_stone)' to confirm.) Is the exception properly recorded? Is it possible (easy?) to send the traceback upstream to us? Device.__init__() is four lines of code, and depends on util.unique_id() and gobject.GObject.__init__(). Device.__init__() sounds like the sort of thing that I expect will be overridden by subclasses in interesting ways and it sounds like the sort of thing that will break when people try to run Sugar on platforms we haven't tested pre-qualified. and no other similar bit of code... does any more checking than this. Is this good? In particular, is it good that an exception that bubbles up through Device.__init__() causes X to enter an infinite restart loop? And please excuse me if I've missed a howler of a bug that you're socraticly/patiently trying to make me realize - just feel free to say outright what sucks and I'll fix it! You seem to be telling me that Sugar will crash if any of its device abstractions fails to initialize. That seems like a howler of a bug to me (though perhaps not one in your code). Is this desirable behavior? Is it intentional? Thanks for putting up me, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
