An OLPC Development Model

[david at lang.hm]

On Wed, 7 May 2008, Martin Langhoff wrote:

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

they could be, but from what I see watching the list since I received my 
G1G1 machine, many things have been tightly integrated that probably 
shouldn't have been.

ubuntu takes packages maintaned externally and picks what version of each 
of those packages to put in the main distro. the versions of these 
seperate packages are almost entirely independant of each other. they then 
do a lot of testing and some development of adminitrative tools and ship 
the result.

unfortunantly much of the OLPC development has seemed to be against the 
idea of having external software run unmodified on sugar, and the 
resulting work to get anything running will hurt this model.

David Lang

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