[Sugar-devel] Activity platform discussion

[David Farning]

Alsroot,

Somethings to keep in minds while you are working on these policies.

1.  Right now, the code churn rate is very high.  In the beginning,
all projects have high churn rates which settle down as the product
becomes more stable and widely used.  Issues which seem large right
now will fade away as Sugar stabilizes.

2.  If Sugar Lab's 'distributes it' we will need to support it.
Supports cost are high, particularly when testers have to isolate
which variants have issues.

3.  School seldom update their software more then once every two years.

For the last two releases we have been focusing heavily on the needs
of the developers.  Now, the development process is running well.  I
encourage you to focus on, 'What policies are best from a long term
maintenance and and support point of view.'

Don't worry too much about getting the policy 100% correct the first
time.  They can be updated and improved.

These policies are essentially agreements between core developers and
activity developers and agreements between Sugar Labs and down stream
about what to expect.

thanks
david

On Fri, Mar 20, 2009 at 12:52 AM, Aleksey Lim <alsroot at member.fsf.org> wrote:
> On Thu, Mar 19, 2009 at 09:00:38PM -0400, Wade Brainerd wrote:
>> On activities.sugarlabs.org we are able to say what platforms a
>> particular activity supports.
>>
>> Note that this is in *addition* to describing the Sugar application
>> version (0.82, 0.84, etc).  So the platform support has more to do
>> with Python version (2.5 vs 2.6), available system packages,
>> architecture, etc.
>>
>> Currently we have:
>>
>> OLPC Software Release 8.2.0 (Build 767)
>> Sugar on a Stick 1 (F10 based)
>> Sugar on a Stick 2 (F11 based)
>>
>> Questions:
>>
>> - Are there other OLPC builds we should add to the list?
>>
>> 656?
>> Others?
>>
>> - How should we describe the distributions such as Caixa Magica?
>>
>> We now have the "Sugar Platform 0.84" package set which is present in
>> many distributions, so alsroot suggested that we simply advertise
>> support for "SP 0.84" and drop the idea of platforms.
> Since we have binary blobs in activities, the idea of "only SP" is useless.
>
> In that case platforms tree on ASLO could include at least 1+2 levels:
> - sugar version(SugarPlatform): All, 0.82 or 0.84
> - OS: All(for activities w/ blobs), GNU/Linux, BSD, Mac ...
> - architecture: All(for activities w/ blobs), x86, x86_64, PPC64, MIPS ...
>
> Activity w/ chosen OS/ARCH options should include binaries for these OSs/ARCHs
>
> Well, a bit confusing for non-tech users, but:
> - its only for activities w/ binary blobs
> - we could pre-filter list of accessible activities on ASLO for specific
>  machine by parsing Browse's useragent string
> - ...and we could rethink idea of blobs in activities
>
> Moreover for the first time it could be collapsed to "only SP" with
> OS switched to only GNU/Linux, architecture to only x86/x86_64
>
>> But there are
>> differences like Python 2.5 (SoaS1) vs 2.6 (SoaS2) that are
>> independent of the SP.
> I guess these differences won't be very popular(otherwise they should be
> included in SugarPlatform specification) and activities could resolve it
> by themselves(like json problem in python2.5/2.6)
>
>> My thought is to add one more platform: "Linux with Sugar Platform
>> 0.84" to cover these.
> yup, thats another direction to go.
>
> But scheme w/ "Linux with Sugar Platform 0.84" has a bit of skewness:
> OLPC-767, soas-{1,2} are concrete platforms and could be dropped
> from time to time, new platforms could be included as well(like soas-3)
>
> It means we'll have to track all these platforms.. and confuse users by
> including/excluding new/old platforms all time(even within one sugar
> release cycle) -- it contrasts with idea of only SP-0.82/0.84/x
>
> --
> Aleksey
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>