An OLPC Development Model

[C. Scott Ananian]

[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/ )