An OLPC Development Model

[Martin Langhoff]

On Wed, May 7, 2008 at 8:52 AM, C. Scott Ananian <cscott at cscott.net> wrote:
>  The model is simple: fork and merge.  That is to say, rather than
>  trying to maintain a single "upstream" that follows all the

That thread you point out is a good resource to understand how current
kernel devs handle things, and I agree with the fork-and-merge
approach. Now, Linux is _one_ software project, and to an extent, our
efforts are closer to what Ubuntu does.

So IMHO...

 - In all tiers, it only makes sense to fork-and-merge if you have
subsystem maintainers. If you don't, stick to a shared tree or - if
there is a clear lead dev, send him/her patches.
 - In all tiers, if you just have a patch of two, just send them as patches.
 - For activities, each main lead dev decided, but should recommend
that they sync with Sugar's cycles, and publish a branch or tag
matching a Sugar milestone.
 - Sugar "base" (libs, wm, etc) can follow the fork-merge-stabilise
cycle - depending on API stability and number of devs, it might make
sense to make each cycle longer.
 - For packages where we are the downstream, maintain external patches
as needed.

>  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,

That makes sense if (when) there is enough people - the overhead of
maintaining and testing additional builds is important.

> an "activities" build which tries to collect all the best activities from
>  the community, etc.

I want to have that "activities" build too 8-)

cheers,


m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff