[this is pretty technical, feel free to skip ahead to the 'project ideas' email if development models don't interest you.]
A recent thread on the linux-kernel mailing list has given me some insight on OLPC's problems interacting with external developers. At the bottom of this email, I'll give you pointers to a number of interesting emails, and you can follow the thread and come to your own conclusions. But first, let me propose a simple model which will, I hope, unblock external developers and eliminate some of the roadblocks people seem to encounter when they try to work with OLPC. The model is simple: fork and merge. That is to say, rather than trying to maintain a single "upstream" that follows all the development on a dozen projects at once, instead let's encourage people to create their own purpose-driven builds to work on their features. For example, we may have a "sugar" build with the latest sugar UI bits, a "security" build which implements Bitfrost more fully, a "printers" build which works on printer support, an "activities" build which tries to collect all the best activities from the community, etc. Some of these may be generated and hosted at OLPC, but I hope many will come from the community as they scratch their itches. The builds should be stand-alone and fully demonstrate a feature (or bug fix!). At intervals -- we'll say, "the first week of the month" for now, we'll have a merge window. During the merge window, all the build maintainers send in their patches against upstream -- "fully working" patches, which have been tested in a build -- and we'll integrate them or comment on and reject them, for resubmission in the next window. The three weeks before the next merge window are spent stomping out bugs in the mainline tree which were introduced by the merge, and of course by the build maintainers who are working on new features in their builds. Preparing appropriate "patches" against upstream is currently rather difficult: you have to hunt down the affected RPM, and then negotiate with upstream or the Fedora or OLPC maintainer. Hopefully we'll come up with "best practices" after a while which will make it as easy as possible for us to merge your patches. But the first step is to get the code written and the builds made, so submit your patches in whatever form makes the most sense to you, and we'll worry about the upstream integration. Our documentation on how to make your own build is pretty spartan right now, but starting with http://wiki.laptop.org/go/Building_custom_images http://wiki.laptop.org/go/Puritan is a good start. The http://wiki.laptop.org/go/Olpc-update page has information which will let you olpc-update to your custom build. Try the process out and help us document it better! --scott A linux-kernel reading list, with my brief & cryptic comments. 'lt' indicates mail by Linus Torvalds, 'am' is Andrew Morton: lt: outlines problem w/ olpc: we try to stop development in order to stabilize http://thread.gmane.org/gmane.linux.kernel/673777 am: use of persuasion, plus 'testing' branch: http://article.gmane.org/gmane.linux.kernel/673787 lt: short merge window, plus 3-6 weeks to stabilize: http://article.gmane.org/gmane.linux.kernel/673790 http://article.gmane.org/gmane.linux.kernel/673796 lt: dangers of formalized process http://article.gmane.org/gmane.linux.kernel/674072 lt: no sticks! don't let unrelated issues block patches http://article.gmane.org/gmane.linux.kernel/673961 lt: quality = removing barriers, not adding them. http://article.gmane.org/gmane.linux.kernel/674026 lt: We always *will* have new code, hopefully. http://article.gmane.org/gmane.linux.kernel/674256 lt: "just spend time looking at other people's code" == drug-induced dreaming http://article.gmane.org/gmane.linux.kernel/674339 [note followup where lt explained that he wasn't insulting testers] lt: quality = distribution http://article.gmane.org/gmane.linux.kernel/674038 lt: long queues = worse quality. http://article.gmane.org/gmane.linux.kernel/674009 -- ( http://cscott.net/ ) _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
