The is an example of the opportunities and potential challenges that can occur between the community and the Association. This is why I was very pleased that the XSCE-XS thread last week shifted to clarification.
The motivations and drives behind community volunteer decisions can be very different than the motivations and drives behind the decisions of an Association employee. As expressed in this thread, when working with large and remote deployments, the Association must be very risk adverse. Sending a qualified engineer to diagnose and fix a flakey SD card can take days... during which time their reputation takes a beating. I have some experience wearing those shoes :( Hackers like George and Mikus, who have the time and talent to drive XSCE forward, are much less risk averse. They can swap SD cards and reboot in a couple of seconds... while they take a break to refill their coffee :) The question becomes how can the community and Association work together to encourage innovative and useful work, while providing backstops to prevent fragile code from entering the OLPC support pipeline. My suggestion is to think of the relationship between XSCE and the Association as a funnel rather than a pipeline. XSCE will have a lot of ideas. The modular structure of XSCE enables all these ideas, both the good and the bad, to coexist. Over time, the good ones will raise to the top. Some examples of this in practice at the community level: 1. Each feature in XSCE is developed in a branch. When the core developers are happy with the quality they agree to merge it into master: 2. Each feature must pass basic 'smoke tests' before being included in the release notes. It might be useful for an organization like the Association to take a subset of XSCE (include only the bits you trust and need) and run some additional layers of QA before endorsing it as a product. As long as we can focus on 'the funnel' and our areas of overlapping interest without getting too caught up in our differences, it is likely the project will add value to both the community and the Association. This example is particularly important to me. As one of the tireless trio -- consisting of Jerry, George, and Tim. George has done the lion's share of the development on XSCE. Due to his experience and ability to clearly communicate, I bookmark a embarrassing number emails written by James so that I can 're-ask' the questions during key parts of the decision making process. On Fri, Aug 9, 2013 at 6:04 PM, James Cameron <qu...@laptop.org> wrote: > On Fri, Aug 09, 2013 at 08:31:27AM -0500, Mikus Grinbergs wrote: >> On 08/09/2013 06:17 AM, James Cameron wrote: >> >I have never been happy with using the >> >XO-1 SD card slot. >> >> I have been using SD cards in the XO-1 SD card slot for more than >> five years now. Although I have experienced occasions of SD card >> corruption, they have been so rare as to not affect what I've been >> doing with my XO-1 systems (I just "clean" the SD card and keep on >> using it). In those five years I have had maybe five SD card >> failures (the SD card stops responding electrically) out of a pool >> of about 40 cards -- I consider my SD cards to have provided me >> "acceptable reliability". [Contrast that with my experience with >> XO-1.5 systems - four out of ten failed (admittedly, the failures >> were early systems).] > > Yes, you have gone through the effort of finding 35 out of 40 cards > capable of operating well with the faulty hardware. ;-) That's > something that an XSCE deployer probably can't afford, especially if > the site is remote. > >> By providing a swap partition on the SD card, I've been able to run >> *large* Linux applications (e.g., BOINC, gvSIG) on the XO-1, despite >> its limited main memory (I run them from Terminal in the Sugar >> environment, and live with the limited multi-window capability >> provided by Sugar). What I place on the SD card is executables >> (e.g., Adobe, Java, Browsers, Sugar Activities (3GB+), Timidity) and >> data (mainly accessed through Terminal - Movies, Books, Music, >> Images, Maps, etc.). >> >> Without my 'permanent' SD card. the XO-1 would be "too little" for >> me. > > I agree swap can be very useful. I like swap over network block > device using USB ethernet. The size of the swap can be unlimited (a > sparse file), additional swap spaces can be added as needed, there's > no worry about SD card compatibility, and no worry about endurance of > FLASH in the card or USB drive. Sustainability. > > http://wiki.laptop.org/go/Swap#Swap_to_network_block_device > > -- > James Cameron > http://quozl.linux.org.au/ > _______________________________________________ > Server-devel mailing list > Server-devel@lists.laptop.org > http://lists.laptop.org/listinfo/server-devel -- David Farning Activity Central: http://www.activitycentral.com _______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel