On Wed, May 7, 2008 at 8:52 AM, C. Scott Ananian <[EMAIL PROTECTED]> 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 -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel