Re: phpmyfaq - url
Sorry. Losing it. http://aaa.opensourcehost.com/~thoughts/faq/ Hats off to everyone and best wishes towards 11/2. BTW it looks like it has some good translation management functionality too. able to run multilingual interface from the get go. haven't scratched deep but i'm hoping once an faq is in english another person could come along and translate to another language. FAQ vs. wiki? I think it could be FAQ + wiki, in partnership. main value seems to be ranking, and ease of facilitating questions. I think members can answer questions too. for end users, this could also help to scale out on b1g1 and interventions on bugs and stuff. On 10/26/07, Todd Kelsey [EMAIL PROTECTED] wrote: Hi, Finally got phpmyfaq instance up (courtesy of working with opensourcehost) will be setting up under subdomain alias, for now it is at an ip. PHPMyFaq is scalable, multilingual, RSS, XML, basically allows people to post questions, other people to answer, print out, save to pdf, xml. coolest thing is ranking -- so most relevant/popular items float to top. I think OLPC needs multiple instances for multiple categories. Was thinking mainly how to try and help pull off redundant questions draining core developers in immediate term. then it's a good way to field questions for community development and different projects. Could really use 1 or more people's help on: -defining categories of questions that developers get asked -some pre-made questions and answers to seed page -more than happy to give admin access; if there's an olpc staff member or volunteer developer(s) who could go in and work with it, I think it would be worth your time. it's easy in, easy out. -would be nice to have someone to moderate instances. -ex: right now i have software/hardware. could be a separate instance for each. benefit of separate instances is ranking. I'm assuming this could be helpful. It could also cross link to wiki. Some people going on wiki may not know what they're looking for, so having a dynamic faq, especially right before people hop on IRC, or where people join lists, could help reduce drain on dev. -Todd -Todd -- Todd Kelsey 630.808.6444 -- Todd Kelsey 630.808.6444 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: phpmyfaq - to take heat off developers
On Fri, Oct 26, 2007 at 01:47:29AM -0500, Todd Kelsey wrote: PHPMyFaq is scalable, multilingual, RSS, XML, basically allows people to post questions, other people to answer, print out, save to pdf, xml. coolest thing is ranking -- so most relevant/popular items float to top. Does it send mail to a special list and allow replies from experts via mail? That is the preferred option for developers, usually. The more interfaces the better. If it is restricted to only HTTP, it won't get much of my bandwidth. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: T-shirt ideas / feedback
Nice, but why not One (billion) Laptop(s) Per (billion) Child(ren)? On 10/24/07, Seth Woodworth [EMAIL PROTECTED] wrote: Hello everyone, isforinsects here. There have been a couple suggestions for t-shirts floating around on the wiki and elsewhere. http://wiki.laptop.org/go/T-shirts I think that it's a great way to build community, and increase awareness so I mocked up a few ideas in InDesign. http://wiki.laptop.org/go/Image:Shirt_10_million.png (more to come) There are several great ideas on the wiki page, and all of them could become shirts via cafepress if anyone so cared. It would also become a slight revenue stream for OLPC community building if sold via cafepress or similar web-printing outfits. Does anyone have feedback on design and/or any ideas for implementation? I'm not going to go start a store somewhere unless the community is into the idea. Seth ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin Earth Treasury: End Poverty at a Profit http://wiki.laptop.org/go/Earth_Treasury Sustainable MBA student Presidio School of Management ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: phpmyfaq - to take heat off developers
I am cc'ing documentation group on this one. (anne could you check it out?) not sure on email. but an alias could be set up so that it hits the list (which developers could subscribe to), and I don't know if it is good enough to automatically process back into the content base (is there a system that does that?) -- but maybe we could find a volunteer to route those kind of questions. i think a group from germany makes it -- so we could ask them to work on that. On 10/26/07, James Cameron [EMAIL PROTECTED] wrote: On Fri, Oct 26, 2007 at 01:47:29AM -0500, Todd Kelsey wrote: PHPMyFaq is scalable, multilingual, RSS, XML, basically allows people to post questions, other people to answer, print out, save to pdf, xml. coolest thing is ranking -- so most relevant/popular items float to top. Does it send mail to a special list and allow replies from experts via mail? That is the preferred option for developers, usually. The more interfaces the better. If it is restricted to only HTTP, it won't get much of my bandwidth. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Todd Kelsey 630.808.6444 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: T-shirt ideas / feedback
I guess the beauty of keeping cafepress around even when there are other options is you don't have to decide. The customer can choose? There are actually some funny options for apparel that are not activated. -Original Message- From: Edward Cherlin [EMAIL PROTECTED] Subj: Re: T-shirt ideas / feedback Date: Fri Oct 26, 2007 2:46 am Size: 1K To: Seth Woodworth [EMAIL PROTECTED] cc: devel@lists.laptop.org Nice, but why not One (billion) Laptop(s) Per (billion) Child(ren)? On 10/24/07, Seth Woodworth [EMAIL PROTECTED] wrote: Hello everyone, isforinsects here. There have been a couple suggestions for t-shirts floating around on the wiki and elsewhere. http://wiki.laptop.org/go/T-shirts I think that it's a great way to build community, and increase awareness so I mocked up a few ideas in InDesign. http://wiki.laptop.org/go/Image:Shirt_10_million.png (more to come) There are several great ideas on the wiki page, and all of them could become shirts via cafepress if anyone so cared. It would also become a slight revenue stream for OLPC community building if sold via cafepress or similar web-printing outfits. Does anyone have feedback on design and/or any ideas for implementation? I'm not going to go start a store somewhere unless the community is into the idea. Seth ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin Earth Treasury: End Poverty at a Profit http://wiki.laptop.org/go/Earth_Treasury Sustainable MBA student Presidio School of Management ___ 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: ip4-address buddy property - still needed?
On Fri, Oct 26, 2007 at 12:20:01AM -0400, Giannis Galanis wrote: The feature, although not usable by the activities, it has other benefits. By observing the buddy list, you acquire instant information of the network connection go the users: when connected to channel 1 for example: 169.254.x.x address are in link-local 172.18.x.x are connected to schoolserver when connected to a jabber server: 169.254.x.x are connected through an MPP 18x.x.x are media lab 172.18.x.x are connected to schoolserver in olpc etc It is information continuously used in network testing, For the link-local case you can just ask avahi for this information directly. For the jabber/server case, i'm unsure why your interested in how other nodes are connected to the jabber server in the first place. also useful from the users prespective: 1. in the case of connecting to multiple jabber servers, the user should be able to tell which XO in the neighbout view belongs to the same school Maybe this has changed. But afaik there will be one jabber server per school (on the school's server) and you can thus look at the users jid. 2. get the geopraphical location of another user A much better way for doing this would be to integrate some geoclue[0] information into telepathy. Instead of having each XO's trying to work out where others are by the small amount of information an ip reveals. In future versions of the neighbor view, or through other activities, the user should be able to filter for specific XOs according to location, or school(in the case he's connected to many servers). Two children in the same school should be able to recognize each other even if they are connected through a jabber server, other then the one in the school. An xo should always connect to the same jabber server afaik.. It can also be useful for locating an XO in case of theft. In the case of theft the jabber server the XO is connecting to always has the information of where a connection came from (or at least of the last nat hop and you can work from there). I don't see the point of pushing that info to all xo's. I have also added a ticket(4405) for adding the public id in the buddy list properties. It is a small part of data(both IPs, private and public), which can be harmfully incorporated in the telepathy services. I definately agree that having some information of where in the world your buddy's are is something very nice. I disagree that exposing ip addresses is the way to do it though. Sjoerd 0: http://www.freedesktop.org/wiki/Software/GeoClue -- Mediocrity finds safety in standardization. -- Frederick Crane ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 26 Oct 2007 at 00:20:01 -0400, Giannis Galanis wrote: The feature, although not usable by the activities, it has other benefits. By observing the buddy list, you acquire instant information of the network connection go the users: when connected to channel 1 for example: 169.254.x.x address are in link-local 172.18.x.x are connected to schoolserver Wouldn't it be better if the information that was exposed was the information you actually want, rather than a coincidental factoid from which you can guess it? I'm connected to the mesh vs I'm connected via school server foo.schools.laptop.org vs I'm connected to some other random access point. 1. in the case of connecting to multiple jabber servers, the user should be able to tell which XO in the neighbout view belongs to the same school Users should only need to connect to multiple Jabber servers if they want multiple distinct identities (e.g. I have a personal Jabber account and a work Jabber account). This seems an unlikely goal for OLPC. If two users on different Jabber servers want to communicate, the way that is done is that their servers communicate with each other (each user connects only to their own server, which stores and forwards messages, just like e-mail). For instance if a Google Talk user talks to a jabber.org user, a typical message path would be something like: [EMAIL PROTECTED] - talk.google.com server - jabber.org server - [EMAIL PROTECTED] When we add inter-server communication (#3371, currently scheduled for 1.1) that's the model we should follow, because it's how the protocol already works. At the moment OLPC is only using a subset of the information. The fact that the school server is likely to be geographically close to the user is another OLPC-specific simplification, which is not required by the Jabber protocol. Most jhbuild instances use olpc.collabora.co.uk as their Jabber server; this happens to be on our server in London, but as long as you have an IP route to the Internet, it doesn't actually matter whether you're in an Internet cafe, the MIT Media Lab, the Collabora UK office or whatever. The underlying Telepathy connection managers are fully aware of which server the user is on (the part of the JID after the @); Presence Service currently hides this, in an attempt to provide a simplified view to activities. It would be entirely possible to expose additional information, or for interested activities to query the Telepathy connection manager directly. 2. get the geopraphical location of another user In future versions of the neighbor view, or through other activities, the user should be able to filter for specific XOs according to location, or school(in the case he's connected to many servers). Two children in the same school should be able to recognize each other even if they are connected through a jabber server, other then the one in the school. If what you want is geographical location, please ask for geographical location. IP address is a poor approximation, particularly since the public IP address may not be well-defined. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHIdabWSc8zVUw7HYRAjB5AKCJwAVcT43BOwTwWE3Mp4joTMVtVgCgrH6z yCWo9Rc5gR9j9va3sns+smY= =BcPE -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
At this point in time, having as much debug info available in the developer console without having to remember which command-line tool provides what, is crucial for collecting problem reports from non-expert users and I would request that the IPv4 information remains where it is. Michail ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Monday Ship Mtg update message
On Oct 25, 2007, at 16:04 , Kim Quirk wrote: For individual activities we will always want people to be able to download from a website pretty much at any time, so further development and features to activities, should continue to be planned and released outside of the olpc schedule. So you mean a downloaded activity in ~/Activities should take precedence over the default one in /usr/share/activities? Has this been tested? Also, does installing updated rpms require a developer key? - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New build 620
Build 620 ChangeLog Base OS: - kernel - 2.6.22 - 20071025.2.olpc.bbb713f3c2b591f.i586.rpm * OLPC: add C2 and C3 board support -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/changelogs ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New build 620
On 10/26/07, Build Announcer Script [EMAIL PROTECTED] wrote: Build 620 ChangeLog Base OS: - kernel - 2.6.22 - 20071025.2.olpc.bbb713f3c2b591f.i586.rpm * OLPC: add C2 and C3 board support I believe this kernel also has a fix for a suspend/resume bug wad cjb found while in China. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Monday Ship Mtg update message
--- Marco Pesenti Gritti wrote: For individual activities we will always want people to be able to download from a website pretty much at any time, so further development and features to activities, should continue to be planned and released outside of the olpc schedule. So you mean a downloaded activity in ~/Activities should take precedence over the default one in /usr/share/activities? Has this been tested? I don't think that works currently. A ticket would be good, I think it's something we really need to fix for 1.0. Marco --- end of quote --- I believe ticket number 4038 applies to this. Basically, updating activities doesn't work right now, and how it should be handled needs to be decided upon. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
OLPC Software Code Localization - A Few Things I've Noticed
Hi, everyone, In response to Xavier Alvarez' request on 10/25 for translators and coordinators, I decided to get off the sidelines and take a look at OLPC's new Pootle-based L10N infrastructure. Here are a few things I noticed which I think will be of general interest and concern: (0) CASING/NAMING OF PO FILES PROBLEM: (Upper/Lower) Casing of names of po files is inconsistent: For example, in Core there is journal-activity.Journal.po with upper case J for the 2nd occurrence of Journal but then why isn't write.write.po written write.Write.po? This is a small point, but consistent and inuitive naming of these PO files will help everyone. Or am I just failing to understand or intuit what the pattern is supposed to be here? (1) INCONSISTENT NUMBER OF MSGIDs ACROSS DIFFERENT LANGUAGES: The other day when I looked at write.write.po for French, there were only 10 messages in the catalog. Today, I see that there are 36 messages which looks a lot closer to what I myself get from xgettext toolbar.py on the latest code. However, when I checked write.write.po for Thai today, I see that it still has only 10 messages. Solution (Or at least A Question Posing As A Possible Solution): Does everyone agree that there needs to be a way that all of the .po files for all languages get updated with the latest messages extracted via xgettext from the latest codebase (toolbar.py, etc.)? What appears to be happening right now is perhaps that someone decided to work on the French so maybe they ran xgettext against Write Activity's latest toolbar.py and so for French we've now got 36 messages (not all translated -- in fact, Pootle says there are only 9 out of 58 translated and I have no clue where that 58 is coming from because I only find 30 or so when I run xgettext toolbar.py myself). BUT, as nobody has yet worked on Thai, there are only 10 messages present for Thai. I suspect that it is overly optimistic to believe that the best and most willing translators out in the community will always double-check by running xgettext themselves against the latest code to make sure that messages are not missing. So computer-assisted updating of the PO files to contain the very latest set of msgids sounds like a necessary step. (3) SOFTWARE I18N/L10N REVIEW PROCESS: While beginning to translate write.write.po for Thai earlier today, I got to this set of msgids: #: toolbar.py:543 msgid Lower Case List #: toolbar.py:544 msgid Upper Case List These are two msgids from a dropdown list which also includes Numbered List and Bulleted List. The first item thus refers to a list enumerated with lower case Latin letters: a. Item One b. Item Two c. Item Three ... while the second obviously refers to enumerating a list with A, B, C, etc. Do we all recognize what the problem is here? OK, I'm waiting for your answers :-). Yes, it also took me half a second to recognize the problem too! Using Thailand as an example, it is true that Thais will sometimes enumerate lists using Latin upper or lower case letters. But the norm in a Thai document (when one's keyboard in any case is already set to Thai) is to enumerate lists using Thai letters, ก, ข, ค, . . . etc. And of course in the Arabic speaking world it is common to enumerate lists using ت, ب, ا , (aleph, be, te, etc. ... ) And when not enumerating by letters, it is even more common to enumerate by digits, which of course must include native Thai, native Arabic, and a host of other native numbering systems for other languages and scripts. So, in addition to : msgid Numbered List msgid Lower Case List msgid Upper Case List ... we really need to add: msgid Arabic Numbered List ... msgid Devanagari Numbered List ... msgid Thai Numbered List ... etc ... If memory serves me, I believe there may be on the order of 17 or so different native digit sets currently in Unicode. And of course, there need to be msgids for enumerating lists using different, alphabets: msgid Arabic List msgid Devanagari List msgid Thai List Of course we cannot have a drop-down list with hundreds of different list styles. That would be completely innappropriate for school children. So my initial thought is that the Python code for the Write application (and any application that requires a drop-down list with different list styles -- i.e., probably break the whole thing out into a separate reusable class) should
Re: New build 620
Not yet, next one will. On Fri, 2007-10-26 at 14:31 -0400, C. Scott Ananian wrote: On 10/26/07, Build Announcer Script [EMAIL PROTECTED] wrote: Build 620 ChangeLog Base OS: - kernel - 2.6.22 - 20071025.2.olpc.bbb713f3c2b591f.i586.rpm * OLPC: add C2 and C3 board support I believe this kernel also has a fix for a suspend/resume bug wad cjb found while in China. --scott -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New build 620
620 also included an EHCI (usb) workaround for an irq suspend race. 621 will include a libertas fix that allows the wireless device to come back after an EHCI hiccup (and EHCI likes to hiccup). On Fri, 26 Oct 2007 17:18:30 -0400 John (J5) Palmieri [EMAIL PROTECTED] wrote: Not yet, next one will. On Fri, 2007-10-26 at 14:31 -0400, C. Scott Ananian wrote: On 10/26/07, Build Announcer Script [EMAIL PROTECTED] wrote: Build 620 ChangeLog Base OS: - kernel - 2.6.22 - 20071025.2.olpc.bbb713f3c2b591f.i586.rpm * OLPC: add C2 and C3 board support I believe this kernel also has a fix for a suspend/resume bug wad cjb found while in China. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New build 620
ChangeLog updated On Fri, 2007-10-26 at 17:33 -0400, Andres Salomon wrote: EHCI (usb) workaround for an irq suspend race ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New build 621
Build 621 ChangeLog Base OS: - kernel - 2.6.22 - 20071026.1.olpc.57969c0efac7e63.i586.rpm * libertas fix that allows the wireless device to come back after an EHCI hiccup -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/changelogs ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC Software Code Localization - A Few Things I've Noticed
On Friday 26 October 2007 16:54, you wrote: ET Hi, everyone, ET ET In response to Xavier Alvarez' request on 10/25 for ET translators and coordinators, I decided to get off the ET sidelines and take a look at OLPC's new Pootle-based L10N ET infrastructure. ET ET Here are a few things I noticed which I think will be of ET general interest and concern: ET ET (0) CASING/NAMING OF PO FILES PROBLEM: The 'rule' is quite simple (but not necessarily as intuitive as may be expected): given that we are bundling several d.l.o projects into pootle-projects, we need to ensure (or at least minimize the possibility) of having 2 POT files with the same name. Solution? We prefix whatever filename used for the POT in d.l.o with the name of its project... journal-activity.Journal.po --dlo-project-.filename Thus, any 'inconsistencies' are really product of other inconsistencies... they just happen to be more evident (and ugly) within Pootle. ET ET (Upper/Lower) Casing of names of po files is ET inconsistent: For example, in Core there is ET journal-activity.Journal.po with upper case J for ET the 2nd occurrence of Journal but then why isn't ET write.write.po written write.Write.po? ET ET This is a small point, but consistent and inuitive ET naming of these PO files will help everyone. Or am I just ET failing to understand or intuit what the pattern is supposed ET to be here? ET ET (1) INCONSISTENT NUMBER OF MSGIDs ACROSS DIFFERENT ET LANGUAGES: Yes and no. The numbers shown in the statistics do not represent quantity of MSGIDs but WORDS in the file. So I presume that for untranslated strings it takes the MSGID words, and for translated strings, the MSGSTR. Thus two languages with all things translated and upto date, may still show different numbers (although conceptually they are the same). BTW, it does show the number of strings in other 'statistic levels'. Yes, I was quite baffled too... translators are more worried about the word-count than 'lines of code'... ;) In http://solar.laptop.org:5080/projects/xo_core/ LanguageTrans. Fuzzy Untrans. Total Portuguese (Brazil) 162 42% 4 1% 213 56% 379 Spanish 219 62% 0 0% 132 37% 351 While in each language+project [pt_BR] 8 files, 162/379 words (42%) translated [118/247 strings] [es]8 files, 219/351 words (62%) translated [157/234 strings] Note that even Still, there's a difference with the number of strings... see below. ET ETThe other day when I looked at write.write.po for ET French, there were only 10 messages in the catalog. Today, I ET see that there are 36 messages which looks a lot closer to ET what I myself get from xgettext toolbar.py on the latest ET code. ETHowever, when I checked write.write.po for Thai today, ET I see that it still has only 10 messages. ET ETSolution (Or at least A Question Posing As A Possible ET Solution): ET ETDoes everyone agree that there needs to be a way that ET all of the .po files for all languages get updated with the ET latest messages extracted via xgettext from the latest ET codebase (toolbar.py, etc.)? Yes, there's a problem. Reviewing what you've noted, the problem appears to be a mix of things. Just for the record, we are sticking to the POT files found in d.l.o git (not fedora) 1) the POT in dlo only has 9 strings http://dev.laptop.org/git?p=projects/write;a=blob_plain;f=po/write.pot;hb=HEAD 2) the POT creation dates have probably been tampered with externally so it's impossible to determine which one makes sense without going into the source code: FR.PO POT-Creation-Date: 2007-06-21 17:33+0200\n DLO POT POT-Creation-Date: 2007-06-21 17:33+0200\n I personally believe that developers should generate the POT file and make sure that it's in d.l.o git. Overall, I find these inconsistencies a direct result of the messy flow we've had with t.fp.o. As a matter of fact, I've been trying to process the tickets in d.l.o holding PO submissions and things haven't been very nice. The current situation is: 0) only some projects have been injected into Pootle (core and bundled activites, with few exceptions like Etoys) 1) d.l.o POT files are being considered the standard 2) d.l.o PO files have been injected but not fully verified 2.1) many have lost their (UTF-8) encoding 2.2) many PO files seem not to correspond to their POT (1) 3) tickets (submitting PO files) seem to issues noted in (2) On top, some of the quirks and particularities of the tools do seem to get in the way, but I think that most stem from the fact that we don't have a 'base' POT population. Still working on it, Xavier PS: The issue regarding lists is an interesting issue that I think it may be much broader than the XO... :) ...snip... ET ET Questions, suggestions, ideas, etc. are all welcome! ET ET ET Cheers, ET Xavier ET ET
Re: [PATCH] More control on LED behavior.
On Wed, 24 Oct 2007 15:42:29 -0700 (PDT) Javier Cardona [EMAIL PROTECTED] wrote: From: Brajesh Dave [EMAIL PROTECTED] See https://dev.laptop.org/ticket/2384#comment:4 Requires firmware version 5.110.19.p0 or newer, available here: http://dev.laptop.org/pub/firmware/libertas/ Signed-off-by: Ashish Shukla [EMAIL PROTECTED] Signed-off-by: Javier Cardona [EMAIL PROTECTED] --- Thanks Javier; these 3 have been applied. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Manual/howto discussions tomorrow (Sat the 2th)
We are reviewing the various manuals and how-tos about using the XO and its interfaces tomorrow from 11:00 to 17:00 EST, in the Cambridge office for the hardy souls who are here or have trekked out, and in #olpc-content on freenode, for people online. If you have any documentation, how-to-photos, or manuals that haven't been posted to the OLPC wiki, and aren't planning to attend, please be sure to send a copy by mail or to add a link to them from http://wiki.laptop.org/go/Documentation Cheers, SJ bcc: a few people who have provided manuals and photos over the months. -- +1 617 529.4266 skype: metasj ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
CODE FREEZE COMING!
NOW READ THIS! This is the home stretch for our stable build for first deployment. ZEROTH: THANK YOU for all your hard work and contributions to date Barring unforeseen events, we are now one week from mass production. FIRST: there will be a release after this within a reasonably short period of time, and another after that, and so on, as we have with Trials 1-3. If what you are working on isn't ready, do remember this and make realistic assessments as to whether your software is really able to make the following dates. Remember that in the *first* week of production there will be more systems built than all systems built to date: are you REALLY prepared to handle the resulting bug reports and questions? SECOND: A fundamental difference with this release and (some of) the previous builds is that it must line up with shipment of actual hardware: the train has started moving and we must be on board in time for G1G1 and country deployments. We MUST have the build in hand as these systems go into the distribution channels. These channels take time. THIRD: terminology: as many of you know, we have a build sequence called joyride we've been using for rapid testing. We will be instituting another build sequence under tight change control called killjoy; your software MUST be tested in joyride before it is moved to killjoy. Killjoy will be under tight change control. FOURTH: We must collect source packages for all software; we need to ensure our software can be built reproducibly both for legal reasons and the need to be able to deal with security and support problems in a timely fashion. You will find we will become increasingly insistent that source packages are available. Mako Hill will be inventorying our packages and ensure we have everything. During this week, October 26 through November 1: You should be substantially complete with your development at this date (October 26). If you are not: You MUST notify the community of any significant code you expect will change in the next week. To do this, you MUST create a ticket, tagged killjoy? in the keywords field. You MUST briefly justify your recommendation. You MUST include the date you expect your change will be available for testing in the joyride build. This date MUST be before November 2. You SHOULD tag other people's bugs that you think should be included in killjoy. But remember that there is a finite amount of time and resources available as you make these recommendations, and state your reasoning why you think these fixes must be made by our first deployment release. Each day, the triage team MUST report its work by a process described at http://wiki.laptop.lorg/go/Killjoy_process. Next week, November 2 and after: Stabilization and change control: We spend the time we have fixing bugs that impair platform stability. Changes MUST be approved by the process described at http://wiki.laptop.org/go/Killjoy_process. Questions? Comments? Suggestions? Best Regards, and thanks again, - Jim Gettys P.S. We aren't kidding about the request for suggestions -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
