Re: First Draft Development Process Proposal
On Tue, Jul 1, 2008 at 11:39 PM, Greg Smith [EMAIL PROTECTED] wrote: 4 - Support time frame. GS - I agree that release should be supported until the second subsequent release is out (ala Fedora). Do we have consensus on that? +1 Is it useful for the rest of you already working on the project? Certainly useful for me. Thanks for working on it :) Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
On Sun, Jun 29, 2008 at 11:20, Tomeu Vizoso [EMAIL PROTECTED] wrote: 3) Stable collaboration :) I know this is a hard one. We just put Cerebro into joyride. We think that some activities, such as Read, will be easy to modify to use it. You might try it and see. Which activities do you care about most in this regard? (If you want to play with Cerebro on your existing image, then just install the RPM and poke Polychronis if you need help.) I thought the plan was to find a way to use Cerebro without having to rewrite activities. Has this changed or are you just suggesting a short term solution? Cerebro currently has a different API to Telepathy. I chatted to Polychronis while I was at 1CC, and we are considering (as a short term project) porting Read to the Cerebro API as a test case: to investigate/demonstrate how well collaboration performs using Cerebro, using an activity that has shown problems on the current setup. This will also give an idea between the difference between the functionality offered by telepathy-salut and Cerebro. The medium term plan is to integrate Cerebro into a Telepathy connection manager. This may result in building abstractions (Clique) on top of Cerebro in an inefficient way if the models are very different, as they appear to be - and also without using features that Cerebro offers such as file transfer. In any case it may well be an improvement over salut over a mesh network. Based on this, the long term may involve abstracting out the API that activities and Sugar need, to a general API that can use either the Telepathy API or the full Cerebro API - assuming we can't merge these enough. That's my understanding, which will be adjusted based on further communication :) Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
On Sun, Jun 29, 2008 at 11:26, Tomeu Vizoso [EMAIL PROTECTED] wrote: Bryan Berry wrote: 3) Stable collaboration :) I know this is a hard one. We just put Cerebro into joyride. We think that some activities, such as Read, will be easy to modify to use it. You might try it and see. Which activities do you care about most in this regard? We care most about Write. I will have to test out Cerebro. Maybe I can get Pradosh, our new intern to work on it this week. The collaboration component in Abiword (AbiCollab) is written in C++, and AFAIK Cerebro currently only offers a Python API. I think that AbiCollab is designed to have different network backends, so that may help in writing a new one that used Cerebro (if there was a C-callable API). AFAIK Cerebro offers a D-Bus API, as Telepathy and Presence Service do. But we're still a way off from having Write work on Cerebro. Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
Hi All, Thanks for all the comments on the Development Process. http://wiki.laptop.org/go/Release_Process_Home A few gentle suggestions on managing the input. A - My intention is that this page (http://wiki.laptop.org/go/Release_Process_Home) will be the final page. So please put comments and discussion in the talk section. Feel free to make signed edits to the page if there is consensus. Any typo fixing or additional links and references are also welcome (e.g. does someone have a link and explanation of the OLPC-3 build which they can add to the builds section?). I want to manage comments on the Talk page and on this list if possible. B - The best way to change a section is to offer alternative text and get consensus for it. Write exactly what you think the text should say, post it here and/or on the talk page. Once there are enough +1s we can call it final. A couple of people at 1CC need to sign off eventually but if the community agrees that's pretty certain to be the final word. C - The very best way have your input adopted is to write a section. No takers on the open items yet and there are some major areas ... I should have explained my plan for collecting comment before, sorry. I have no complaints about any of the input so far, keep it coming. Here are my responses to a few of the issues raised: 1 - Translations input GS - I agree we need a better definition of that. I added it to the to do list. 2 - Synching with Fedora schedule GS - No opinion right now. Is there consensus? How long do we need after a fedora release comes out before our release is ready? 3 - Core OS vs Core + Activities GS - My intention was that this doc is for Core OS. I added a to do list item for activities and removed on offending comment. We need a definition of what constitutes the Core OS. I prefer a URL with all relevant SW modules, but whatever developers need is OK. Do we have consensus that this doc is for Core OS only? GS - That said, I think we should keep with current naming convention on Releases used in the field which include activities. The fewer times you change the naming convention the better. Also, I think we should document the naming convention down to the OS + Activities level even if we don't have a process for including activities yet. 4 - Support time frame. GS - I agree that release should be supported until the second subsequent release is out (ala Fedora). Do we have consensus on that? 5 - Code names and community roadmap. GS - I agree with the code name idea and the community roadmap idea. Just type of the text you want on the page including where you want it to go. Post it to the talk section and/or send it to this list, get consensus and its in as far as I'm concerned. 6 - Types of builds, meaning of freezes, definition of what requires a minor release. GS - I agree that those could all be improved. Just type of the text you want on the page including where you want it to go. Post it to the talk section and/or send it to this list, get consensus. Thanks for the review and suggestions. I didn't see anyone commenting on whether this is useful or not. Are there any open source developers reading this who are on the fence about working with OLPC? Does this help explain how we work and does it help motivate you to chip in? Is it useful for the rest of you already working on the project? FYI I have a pre-planned vacation I need to take starting tomorrow. I will be back online Thursday July 10. I will collect all comments and edits then and make another major revision. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
On Tue, Jul 1, 2008 at 5:39 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, Thanks for all the comments on the Development Process. http://wiki.laptop.org/go/Release_Process_Home A few gentle suggestions on managing the input. A - My intention is that this page (http://wiki.laptop.org/go/Release_Process_Home) will be the final page. So please put comments and discussion in the talk section. Feel free to make signed edits to the page if there is consensus. Any typo fixing or additional links and references are also welcome (e.g. does someone have a link and explanation of the OLPC-3 build which they can add to the builds section?). I want to manage comments on the Talk page and on this list if possible. KQ - feel free to move my comments to the talk page. (If I haven't already gotten to it) B - The best way to change a section is to offer alternative text and get consensus for it. Write exactly what you think the text should say, post it here and/or on the talk page. Once there are enough +1s we can call it final. A couple of people at 1CC need to sign off eventually but if the community agrees that's pretty certain to be the final word. C - The very best way have your input adopted is to write a section. No takers on the open items yet and there are some major areas ... I should have explained my plan for collecting comment before, sorry. I have no complaints about any of the input so far, keep it coming. Here are my responses to a few of the issues raised: 1 - Translations input GS - I agree we need a better definition of that. I added it to the to do list. 2 - Synching with Fedora schedule GS - No opinion right now. Is there consensus? How long do we need after a fedora release comes out before our release is ready? 3 - Core OS vs Core + Activities GS - My intention was that this doc is for Core OS. I added a to do list item for activities and removed on offending comment. We need a definition of what constitutes the Core OS. I prefer a URL with all relevant SW modules, but whatever developers need is OK. Do we have consensus that this doc is for Core OS only? KQ - I think a 'release' consists of everything needed to put it behind us: core OS, signed core OS with all the parts needed for all the upgrade capabilities (fs.zip, .crc, .img, .md5, .usb?,...); images+activities for all customizations (G1G1, Peru, possibly AL); documentation GS - That said, I think we should keep with current naming convention on Releases used in the field which include activities. The fewer times you change the naming convention the better. Also, I think we should document the naming convention down to the OS + Activities level even if we don't have a process for including activities yet. 4 - Support time frame. GS - I agree that release should be supported until the second subsequent release is out (ala Fedora). Do we have consensus on that? KQ +1 5 - Code names and community roadmap. GS - I agree with the code name idea and the community roadmap idea. Just type of the text you want on the page including where you want it to go. Post it to the talk section and/or send it to this list, get consensus and its in as far as I'm concerned. 6 - Types of builds, meaning of freezes, definition of what requires a minor release. GS - I agree that those could all be improved. Just type of the text you want on the page including where you want it to go. Post it to the talk section and/or send it to this list, get consensus. Thanks for the review and suggestions. I didn't see anyone commenting on whether this is useful or not. Are there any open source developers reading this who are on the fence about working with OLPC? Does this help explain how we work and does it help motivate you to chip in? Is it useful for the rest of you already working on the project? FYI I have a pre-planned vacation I need to take starting tomorrow. I will be back online Thursday July 10. I will collect all comments and edits then and make another major revision. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
Ar 29/06/2008 am 11:20, ysgrifennodd Tomeu Vizoso: Michael Stone wrote: Bryan, Thanks very much for the detailed feedback. Here are my comments: 1) Be able to remove activities to free up space, including activities that come pre-installed. Noted. Can you or Bernie supply a patch which accomplishes the desired behavior? If someone can come up with a halfway decent patch, I'm more than happy to try to see that this gets resolved. If possible, try to coordinate with Eben. I think that we can find a simple solution that can be accepted in Sugar and won't need to change in the near future (which could be a problem from the support point of view). (This may be better discussed in trac) 3) Stable collaboration :) I know this is a hard one. We just put Cerebro into joyride. We think that some activities, such as Read, will be easy to modify to use it. You might try it and see. Which activities do you care about most in this regard? (If you want to play with Cerebro on your existing image, then just install the RPM and poke Polychronis if you need help.) I thought the plan was to find a way to use Cerebro without having to rewrite activities. Has this changed or are you just suggesting a short term solution? I still think that this is the way to go. Elliot Fairweather and I did some work on this based on the telepathy-cerebro repository that Michael created. We're planning to push our work to a public repository soon. -- Dafydd ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
On Sun, Jun 29, 2008 at 6:01 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Sun, Jun 29, 2008 at 5:07 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: and I formally request synchronizing our release schedule with Fedora's. That would be good, how can we do it though? A short 8.3 in November this year to get in sync? Fedora releases in November and May. We could plan to release in late-November (just before Thanksgiving) and June. To sync up, I think a short 8.3 might be pushing it a bit; I'd suggest taking the 10 months between August and June and making two 5 month release cycles, so that we release in January (9.1, based on F10) and June (9.2, based on F11), and are then synced up for a regular November/June schedule. That's just my first shot at a proposal, though: there might be better ideas out there. In particular, the Fedora's November release date was specifically designed to avoid Thanksgiving and winter holidays in December. I'm a little concerned that (a) if we follow Fedora too closely it will be too hard to have Fedora making final release changes at the same time we are, but (b) if we lag too far then we'll be freezing at Thanksgiving and releasing at Christmas, which seems... suboptimal. As an alternative which avoids the Christmas trap, we could consider 3 releases a year, in June, October, and February. The June and October releases will be based on the Fedora May release, and the February release will be based on the Fedora November release. This gives us one tight integration in June where we're using the very latest Fedora bits, one free pass in October where we can worry about our own features and not track Fedora, and a leisurely February release with plenty of time to sync up with the changes Fedora's made since November. I think I slightly favor the regularity of the November/June schedule, with the understanding that our November schedule will be tighter (and with a sharper cliff on the other side) than the June schedule. We might be more aggressive about pruning unready features early for November, for example. Here's the historic data on Fedora release dates (note that the November/May schedule started around F7). http://fedoraproject.org/wiki/Releases/HistoricalSchedules If we had ambitious release engineers, we could plan to roll up joyride into Alpha, Beta, and Preview releases synchronized with Fedora as well, but I'd prefer we demonstrate that we can get our basic product out the door on schedule before worrying about other possible end-user products we might provide. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
c. scott ananian wrote: On Sun, Jun 29, 2008 at 6:01 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Sun, Jun 29, 2008 at 5:07 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: and I formally request synchronizing our release schedule with Fedora's. That would be good, how can we do it though? A short 8.3 in November this year to get in sync? why is it necessary or optimal that we track every fedora release? it seems like a requirement that's both ambitious, and somewhat arbitrary. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
On Mon, Jun 30, 2008 at 11:22 AM, [EMAIL PROTECTED] wrote: c. scott ananian wrote: On Sun, Jun 29, 2008 at 6:01 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Sun, Jun 29, 2008 at 5:07 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: and I formally request synchronizing our release schedule with Fedora's. That would be good, how can we do it though? A short 8.3 in November this year to get in sync? why is it necessary or optimal that we track every fedora release? it seems like a requirement that's both ambitious, and somewhat arbitrary. I personally think that it's good to keep your upstream (like your enemies) close -- but I agree that it's not strictly necessary for every release. I do think it's important to have a well-defined relationship with our upstream, though, and since 6-month schedules were being proposed it makes sense to think about how that lines up with Fedora's 6-month schedules. Perhaps you'd like my second, 4-month, proposal better, which gives us a day off from following fedora once in a while. Or, returning to the 6-month proposal, if the November schedule ends up squeezing us too much because of the holidays, propose that we follow every *other* Fedora release, skipping the Fedora release that happens in November. I personally don't have a strong opinion which of these we do (although I suspect Dennis does, since the burden of keeping us in sync with upstream seems to be falling mostly on him), but I do strongly feel that we should have a well-defined and consistent relationship with Fedora's schedule, whatever that turns out to mean. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
c. scott ananian wrote: On Mon, Jun 30, 2008 at 11:22 AM, [EMAIL PROTECTED] wrote: why is it necessary or optimal that we track every fedora release? it seems like a requirement that's both ambitious, and somewhat arbitrary. I personally think that it's good to keep your upstream (like your enemies) close -- but I agree that it's not strictly necessary for every release. I do think it's important to have a well-defined relationship with our upstream, though, and since 6-month schedules were being proposed it makes sense to think about how that lines up with Fedora's 6-month schedules. Perhaps you'd like my second, 4-month, proposal better, which gives us a day off from following fedora once in a while. Or, returning to the 6-month proposal, if the November schedule ends up squeezing us too much because of the holidays, propose that we follow every *other* Fedora release, skipping the Fedora release that happens in November. it's the latter possibility i was thinking of (sync to every other fedora release), but obviously only if we (which, as you say, probably means dennis) thought the net work, and net churn, were lower using that plan. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
On Fri, Jun 27, 2008 at 8:31 AM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, I posted a first pass Release Process Overview. See: http://wiki.laptop.org/go/Release_Process_Home Thank you. Its based on work done by Michael and others on this list. It needs a lot more work, but I hope we can start using it soon and improve it over time. I could use help fleshing it out and closing the open items listed in the final section. Let me know if anyone wants to work with me on that. The goals of this process are: 1 - Ensure high quality releases which meet the needs of users in a timely fashion. 2 - Maximize the participation, productivity and enthusiasm of the open source community. 3 - Create a predictable process which helps users and developers plan for the future. I want to minimize the process overhead as much as possible. If its not helping make coders life easier then its not likely to make better code. Please comment, question, augment and criticize as needed. I especially want to know if it makes sense, looks useful and meets the goals outlined above. Comments on linked pages also welcome, especially: http://wiki.laptop.org/go/Releases and http://wiki.laptop.org/go/Unscheduled_software_release_process Any input welcome. Thanks, Greg Smith OLPC Product Manager PS - This is my first e-mail to the list since I changed from volunteer to employee. It's truly an honor to have this chance to work for OLPC and to learn from you all! Right now, I'm 90% focused on gathering input so I'm open to a call or e-mail exchange with anyone who is contributing to the project. If you want to have a brief call, just send me an agenda and a few open times 7AM - 6PM US ET, Mon - Fri. We don't seem to have any process for translating textbooks and content. There are teacher training materials in Spanish and Nepali that we need in English, and a variety of other content in many languages. I think that we also need to do some work on creating a global conversation on curriculum and free textbooks incorporating Sugar software capabilities, and what we know about how children learn and when they can learn it. I am working with others to create a separate process for researching and deploying other parts of the solution, such as electricity and Internet in villages with microfinance support, parts which are out of scope for OLPC. But we would still like to coordinate our efforts with yours. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
On Mon, Jun 30, 2008 at 6:13 PM, Edward Cherlin [EMAIL PROTECTED] wrote: On Fri, Jun 27, 2008 at 8:31 AM, Greg Smith [EMAIL PROTECTED] wrote: I posted a first pass Release Process Overview. We don't seem to have any process for translating textbooks and content. There are teacher training materials in Spanish and Nepali that we need in English, and a variety of other content in many languages. In general, I think this is the fundamental weakness of the first draft: it mentions that a release consists of core OS + other stuff but really only talks about dates deadlines names for the core OS. I don't think the solution is expanding our scope so that OLPC is responsible for releasing every country's other stuff along with 8.2 at a single release date. I think the solution is to be more explicit about where the hand offs are, what the limits of our development/support are, and what processes are used to support local development. We should write into our release process when we gives bits to local translation, activity, and content teams, and when we need bits back from them, esp. for localization of reference activities and content (library-core, Write, Words) and for reference activities which are not maintained by OLPC (Tam Tam, Etoys, Squeak). There may be a separate release document that outlines the steps we will take to support a planned large-scale deployment, including basic QA of their activities + core OS image, converting it to an image suitable for Quanta and shepherding it through their QA process, QA of keyboards and manufacturing data on local SKUs, etc. This timetable is driven by the deployment, but we should set reasonable expectations for what steps are required, in what order, and how much time is needed for each. I'd also like to see quality expectations set, since the success and reputation of OLPC may depend on the success of these large-scale deployments. This is both technical (their release should work) and aesthetic (icons for local activities should conform to Sugar guidelines, the ordering should be logical, etc). For the bits of non-core OS other stuff we do, we should commit to a schedule. When is the first draft of the release notes available? Are the final versions of the reference activities synchronized with the core OS, or can/do they lag it by a week (or two, or three)? After how long does a release candidate become a release? What happens if there is a critical bug discovered in a not maintained here reference activity? Our biggest weakness to date is not knowing when we're done because the core OS is good enough but the other stuff isn't getting done. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
On Sun, Jun 29, 2008 at 12:01 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Sun, Jun 29, 2008 at 5:07 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: I propose a '8.1+peru-2' system for referring to combinations of core OS + activities I tend to agree. Exposing the raw number of the reference OS. I meant to say, exposing the raw number of the reference OS is confusing. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
re: First Draft Development Process Proposal
Here in nepal, here are the key features we need listed in order of priority: 1) Be able to remove activities to free up space, including activities that come pre-installed. For example, our current E-Paath activities already use up 105 MB and that only covers 1 month of coursework! We intend to have 12 months worth of activities so it will be crucial that students can remove activities easily as necessary, including pre-installed ones like Scratch or TurtleArt 2) Need to be able to launch activities from the web browser. We are moving towards html and likely Moodle to organize our activities together w/ supplementary reading and other materials. The students will use an offline html page and click on links to launch a python or EToys activity in a separate window, and not w/in the browser. This functionality is essential in order to put the activities w/in lesson plans. 3) Stable collaboration :) I know this is a hard one. I believe Trac tickets already exist for #1 and #2, filed by me or by Bernie. 4) Longer battery life, it's ok w/ us if you turn off the mesh while the XO goes into suspend mode. hope this helps Message: 4 Date: Fri, 27 Jun 2008 11:31:06 -0400 From: Greg Smith [EMAIL PROTECTED] Subject: First Draft Development Process Proposal To: devel@lists.laptop.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi All, I posted a first pass Release Process Overview. See: http://wiki.laptop.org/go/Release_Process_Home Its based on work done by Michael and others on this list. It needs a lot more work, but I hope we can start using it soon and improve it over time. I could use help fleshing it out and closing the open items listed in the final section. Let me know if anyone wants to work with me on that. The goals of this process are: 1 - Ensure high quality releases which meet the needs of users in a timely fashion. 2 - Maximize the participation, productivity and enthusiasm of the open source community. 3 - Create a predictable process which helps users and developers plan for the future. I want to minimize the process overhead as much as possible. If its not helping make coders life easier then its not likely to make better code. Please comment, question, augment and criticize as needed. I especially want to know if it makes sense, looks useful and meets the goals outlined above. Comments on linked pages also welcome, especially: http://wiki.laptop.org/go/Releases and http://wiki.laptop.org/go/Unscheduled_software_release_process Any input welcome. Thanks, Greg Smith OLPC Product Manager PS - This is my first e-mail to the list since I changed from volunteer to employee. It's truly an honor to have this chance to work for OLPC and to learn from you all! Right now, I'm 90% focused on gathering input so I'm open to a call or e-mail exchange with anyone who is contributing to the project. If you want to have a brief call, just send me an agenda and a few open times 7AM - 6PM US ET, Mon - Fri. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
On Fri, Jun 27, 2008 at 11:31 AM, Greg Smith [EMAIL PROTECTED] wrote: I posted a first pass Release Process Overview. See: http://wiki.laptop.org/go/Release_Process_Home I'd added a number of comments to that page. Major points: I recommend adopting Fedora's freeze definitions, I propose a '8.1+peru-2' system for referring to combinations of core OS + activities, I ask for clarity on the intended scope of minor releases, and I formally request synchronizing our release schedule with Fedora's. And I offer cranky comments at various points, just to stay in character. =) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: First Draft Development Process Proposal
Michael, thanks for your responses. Michael wrote: Noted. Can you or Bernie supply a patch which accomplishes the desired behavior? If someone can come up with a halfway decent patch, I'm more than happy to try to see that this gets resolved. I will have to ask Bernie for help w/ this. It is beyond my current abilities and I am pretty maxed out right now working on our E-Library. Don't worry we will share back all the config and code we have come up w/. Here are two dirty hacks and a long-term project: I will have to get folks here working on it. Surprisingly, resources are pretty tight here, our developers are in a mad dash to develop enough activities for the kids at the schools. They go through them so quickly and are always clamoring for more English and math activities, esp. English. 3) Stable collaboration :) I know this is a hard one. We just put Cerebro into joyride. We think that some activities, such as Read, will be easy to modify to use it. You might try it and see. Which activities do you care about most in this regard? We care most about Write. I will have to test out Cerebro. Maybe I can get Pradosh, our new intern to work on it this week. (FYI, the configuration management scripting that Martin [and Uruguay, for that matter] have done might be of some interest to you as a labor-savor. Poke Martin or Emiliano [have you met?] for details.) Definitely interested in it, will have to check it out. 4) Longer battery life, it's ok w/ us if you turn off the mesh while the XO goes into suspend mode. This can be manually tested in the latest joyrides. Any help you can offer in testing them would be greatly appreciated, for obvious reasons. I will try to help out w/ testing but the E-Library is kicking my butt right now. thanks, Bryan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
