[Sugar-devel] Sugar and activities flag day

[Gary Martin]

On 20 Sep 2010, at 16:34, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:

> On Wed, Sep 15, 2010 at 01:27, Gary Martin <garycmartin at googlemail.com> wrote:
>> On 14 Sep 2010, at 12:11, Simon Schampijer <simon at schampijer.de> wrote:
>> 
>>> On 09/13/2010 05:58 PM, Daniel Drake wrote:
>>>> On 10 September 2010 13:41, Daniel Drake<dsd at laptop.org>  wrote:
>>>>> Just wanted to summarize an enlightening conversation that just
>>>>> happened in #sugar:
>>>> 
>>>> No responses..surprising!
>>>> Let me try a bit harder then.
>>> 
>>> We all duck and freeze - the old wait until it is over tactic!
>> 
>> Yea, right now I'm doing my deer in the headlights pose. Daniel, thanks for scaring me, I'm having activity maintenance nightmares already.
> 
> Wonder if there's any realistic alternative to branching and having
> all new development happening in master :(
> 
> I know how much it will suck for activity developers who naturally
> want their work to have a direct impact on learners.

Well to be brutal, I'm guessing 70% of activities may well just die (I'm excluding the 100 odd gcompris titles). Only those supported by some keen member of core are likely to move forward (aleksey/gcompris, reasonable amount of Fructose, and some honey).

I guess the open source way is to just let all the rest die and be culled off through lack of longterm contributor commitment, but as an already deployed learning environment there will  be pain, resistance to upgrade Sugar for several years, and plenty of kickback from deployments. Obviously this depends on just how bad the current API is broken when trying to move forward to the new underlying supported technologies.

FWIW: if we are going to royally break with existing activity support, let's make sure we add in touch device hardware support to the list of things that we need to plan to cover.

--Gary

> Regards,
> 
> Tomeu
> 
>>> 
>>>> My thoughts/suggestions:
>>>> 
>>>> 1. Rename sugar-0.92 to Sugar-1.0
>>>> 
>>>> 2. Switch to pygi and GTK+ 3 for sugar-1.0
>>> 
>>> This seem to be inescapable - even if we duck...
>> 
>> I'll stand here, in the headlights, hoping you guys will drive your 4x4 around me and I don't end up on a cold meat slab ;)
>> 
>>> 
>>>> 3. Allow significant sugar API changes up until the sugar-1.0 API
>>>> freeze date, which I think would land mid-January 2011. These would be
>>>> subject to the usual review processes to ensure quality.
>>> 
>>> Yes, API freeze would be mid-January.
>>> 
>>>> 4. Ignore the silly people who draw large conclusions from looking at
>>>> a version number
>>> 
>>> I myself, do not draw too much on version numbers. If you look at the
>>> consequences in support then what we shipped with 0.82 was 1.0.
>>> Personally, I think we could even get away with naming it 0.94 and
>>> announce that we switched to GTK+ 3.
>> 
>> It's looking painful what ever we do, 0.94 does sound a little better to me even with all the breakage, v1.0 has always been a feature complete milestone in my mind - we are still way short of that even given another 6 months or so.
>> 
>> Regards,
>> --Gary
>> 
>>> Regards,
>>>    Simon
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>