Re: [Sugar-devel] Sugar and activities flag day

2010-09-21 Thread Simon Schampijer
On 09/20/2010 09:46 PM, Walter Bender wrote:
> On Mon, Sep 20, 2010 at 3:27 PM, Marco Pesenti Gritti  
> wrote:
>> On Mon, Sep 20, 2010 at 4:40 PM, Tomeu Vizoso  wrote:
>>> The hackers at #python in GIMPNet have proposed holding a hackfest for
>>> porting Sugar to introspection and thus getting PyGObject ready.
>>>
>>> Who else would be interested from the Sugar side? We'll also need
>>> sponsors for travel and venue. Right now Boston, Bolzano and Prague
>>> have been mentioned as possibilities. The GNOME Foundation will be
>>> able to fund some travel but it will be easier to get that funding if
>>> other organizations partner on this one.
>>
>> I might be able to make it if it's in Europe. In the US would probably
>> be more complicated for me.
>
> Then can I through Paris into the mix?
>
> -walter

Berlin might be an option, too. We have conference rooms at buero20 [1] 
where i have my office atm. I will ask them what the situation is like.

Regards,
Simon

[1] http://www.buero20.org/

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-20 Thread Walter Bender
On Mon, Sep 20, 2010 at 3:27 PM, Marco Pesenti Gritti  wrote:
> On Mon, Sep 20, 2010 at 4:40 PM, Tomeu Vizoso  wrote:
>> The hackers at #python in GIMPNet have proposed holding a hackfest for
>> porting Sugar to introspection and thus getting PyGObject ready.
>>
>> Who else would be interested from the Sugar side? We'll also need
>> sponsors for travel and venue. Right now Boston, Bolzano and Prague
>> have been mentioned as possibilities. The GNOME Foundation will be
>> able to fund some travel but it will be easier to get that funding if
>> other organizations partner on this one.
>
> I might be able to make it if it's in Europe. In the US would probably
> be more complicated for me.

Then can I through Paris into the mix?

-walter
>
> (Sounds like a great idea anyway!)
>
> Marco
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-20 Thread Marco Pesenti Gritti
On Mon, Sep 20, 2010 at 4:40 PM, Tomeu Vizoso  wrote:
> The hackers at #python in GIMPNet have proposed holding a hackfest for
> porting Sugar to introspection and thus getting PyGObject ready.
>
> Who else would be interested from the Sugar side? We'll also need
> sponsors for travel and venue. Right now Boston, Bolzano and Prague
> have been mentioned as possibilities. The GNOME Foundation will be
> able to fund some travel but it will be easier to get that funding if
> other organizations partner on this one.

I might be able to make it if it's in Europe. In the US would probably
be more complicated for me.

(Sounds like a great idea anyway!)

Marco
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-20 Thread Gary Martin
On 20 Sep 2010, at 16:34, Tomeu Vizoso  wrote:

> On Wed, Sep 15, 2010 at 01:27, Gary Martin  wrote:
>> On 14 Sep 2010, at 12:11, Simon Schampijer  wrote:
>> 
>>> On 09/13/2010 05:58 PM, Daniel Drake wrote:
 On 10 September 2010 13:41, Daniel Drake  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@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>> 
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-20 Thread Walter Bender
On Mon, Sep 20, 2010 at 11:40 AM, Tomeu Vizoso  wrote:
> On Tue, Sep 14, 2010 at 10:26, Tomeu Vizoso  wrote:
>> On Mon, Sep 13, 2010 at 18:09, Marco Pesenti Gritti  
>> wrote:
>>> On Mon, Sep 13, 2010 at 4:58 PM, Daniel Drake  wrote:
 On 10 September 2010 13:41, Daniel Drake  wrote:
> Just wanted to summarize an enlightening conversation that just
> happened in #sugar:

 No responses..surprising!
 Let me try a bit harder then.

 My thoughts/suggestions:

 1. Rename sugar-0.92 to Sugar-1.0

 2. Switch to pygi and GTK+ 3 for sugar-1.0

 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.
>>>
>>> The time might be a bit short to do both porting and API changes. An
>>> alternative would be to have a longer unstable cycle (probably in
>>> parallel to a stable 0.92). I have the feeling that porting stable
>>> changes to unstable for a long time might be too much work for us
>>> though. So perhaps we really have to break API two times (1.0 and
>>> 2.0)...
>>
>> One way of seeing things that might make more palatable 0.92 == 1.0 is
>> that we are really still in the first iteration and 1.0 will be when
>> that first iteration reaches maturity, without big changes in the API.
>> After 1.0 we can start working on what will be one day 2.0 which
>> should be the second iteration of Sugar, hopefully using what we have
>> learned during these years.
>>
>> This would mean that the next cycle would be devoted to rebasing on
>> top of GNOME 3 so we remain packageable in future distros and that the
>> next-gen activity APIs would only come afterwards.
>
> The hackers at #python in GIMPNet have proposed holding a hackfest for
> porting Sugar to introspection and thus getting PyGObject ready.
>
> Who else would be interested from the Sugar side? We'll also need
> sponsors for travel and venue. Right now Boston, Bolzano and Prague
> have been mentioned as possibilities. The GNOME Foundation will be
> able to fund some travel but it will be easier to get that funding if
> other organizations partner on this one.

I'd be interested. We can probably get a venue in Miami as well...
which may be more likely to attract some of our colleagues from LA.

-walter

>
> Regards,
>
> Tomeu
>
>> How does it sound?
>>
>> Regards,
>>
>> Tomeu
>>
>>> Marco
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-20 Thread David Farning
On Mon, Sep 20, 2010 at 10:40 AM, Tomeu Vizoso  wrote:
> On Tue, Sep 14, 2010 at 10:26, Tomeu Vizoso  wrote:
>> On Mon, Sep 13, 2010 at 18:09, Marco Pesenti Gritti  
>> wrote:
>>> On Mon, Sep 13, 2010 at 4:58 PM, Daniel Drake  wrote:
 On 10 September 2010 13:41, Daniel Drake  wrote:
> Just wanted to summarize an enlightening conversation that just
> happened in #sugar:

 No responses..surprising!
 Let me try a bit harder then.

 My thoughts/suggestions:

 1. Rename sugar-0.92 to Sugar-1.0

 2. Switch to pygi and GTK+ 3 for sugar-1.0

 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.
>>>
>>> The time might be a bit short to do both porting and API changes. An
>>> alternative would be to have a longer unstable cycle (probably in
>>> parallel to a stable 0.92). I have the feeling that porting stable
>>> changes to unstable for a long time might be too much work for us
>>> though. So perhaps we really have to break API two times (1.0 and
>>> 2.0)...
>>
>> One way of seeing things that might make more palatable 0.92 == 1.0 is
>> that we are really still in the first iteration and 1.0 will be when
>> that first iteration reaches maturity, without big changes in the API.
>> After 1.0 we can start working on what will be one day 2.0 which
>> should be the second iteration of Sugar, hopefully using what we have
>> learned during these years.
>>
>> This would mean that the next cycle would be devoted to rebasing on
>> top of GNOME 3 so we remain packageable in future distros and that the
>> next-gen activity APIs would only come afterwards.
>
> The hackers at #python in GIMPNet have proposed holding a hackfest for
> porting Sugar to introspection and thus getting PyGObject ready.
>
> Who else would be interested from the Sugar side? We'll also need
> sponsors for travel and venue. Right now Boston, Bolzano and Prague
> have been mentioned as possibilities. The GNOME Foundation will be
> able to fund some travel but it will be easier to get that funding if
> other organizations partner on this one.
>
> Regards,
>
> Tomeu
>
>> How does it sound?

I can't afford travel yet:( But I can commit all of AC's developers to
work remotely for the duration of the sprint.

david
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-20 Thread Tomeu Vizoso
On Tue, Sep 14, 2010 at 10:26, Tomeu Vizoso  wrote:
> On Mon, Sep 13, 2010 at 18:09, Marco Pesenti Gritti  wrote:
>> On Mon, Sep 13, 2010 at 4:58 PM, Daniel Drake  wrote:
>>> On 10 September 2010 13:41, Daniel Drake  wrote:
 Just wanted to summarize an enlightening conversation that just
 happened in #sugar:
>>>
>>> No responses..surprising!
>>> Let me try a bit harder then.
>>>
>>> My thoughts/suggestions:
>>>
>>> 1. Rename sugar-0.92 to Sugar-1.0
>>>
>>> 2. Switch to pygi and GTK+ 3 for sugar-1.0
>>>
>>> 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.
>>
>> The time might be a bit short to do both porting and API changes. An
>> alternative would be to have a longer unstable cycle (probably in
>> parallel to a stable 0.92). I have the feeling that porting stable
>> changes to unstable for a long time might be too much work for us
>> though. So perhaps we really have to break API two times (1.0 and
>> 2.0)...
>
> One way of seeing things that might make more palatable 0.92 == 1.0 is
> that we are really still in the first iteration and 1.0 will be when
> that first iteration reaches maturity, without big changes in the API.
> After 1.0 we can start working on what will be one day 2.0 which
> should be the second iteration of Sugar, hopefully using what we have
> learned during these years.
>
> This would mean that the next cycle would be devoted to rebasing on
> top of GNOME 3 so we remain packageable in future distros and that the
> next-gen activity APIs would only come afterwards.

The hackers at #python in GIMPNet have proposed holding a hackfest for
porting Sugar to introspection and thus getting PyGObject ready.

Who else would be interested from the Sugar side? We'll also need
sponsors for travel and venue. Right now Boston, Bolzano and Prague
have been mentioned as possibilities. The GNOME Foundation will be
able to fund some travel but it will be easier to get that funding if
other organizations partner on this one.

Regards,

Tomeu

> How does it sound?
>
> Regards,
>
> Tomeu
>
>> Marco
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-20 Thread Tomeu Vizoso
On Wed, Sep 15, 2010 at 01:27, Gary Martin  wrote:
> On 14 Sep 2010, at 12:11, Simon Schampijer  wrote:
>
>> On 09/13/2010 05:58 PM, Daniel Drake wrote:
>>> On 10 September 2010 13:41, Daniel Drake  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.

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@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-14 Thread Gary Martin
On 14 Sep 2010, at 12:11, Simon Schampijer  wrote:

> On 09/13/2010 05:58 PM, Daniel Drake wrote:
>> On 10 September 2010 13:41, Daniel Drake  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.

> 
>> 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@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-14 Thread Marco Pesenti Gritti
On Tue, Sep 14, 2010 at 12:11 PM, Simon Schampijer  wrote:
> 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.

Exactly!

Marco
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-14 Thread Walter Bender
On Tue, Sep 14, 2010 at 7:18 AM, Simon Schampijer  wrote:
> On 09/14/2010 11:08 AM, Marco Pesenti Gritti wrote:
>> On Tue, Sep 14, 2010 at 9:26 AM, Tomeu Vizoso  wrote:
>>> One way of seeing things that might make more palatable 0.92 == 1.0 is
>>> that we are really still in the first iteration and 1.0 will be when
>>> that first iteration reaches maturity, without big changes in the API.
>>> After 1.0 we can start working on what will be one day 2.0 which
>>> should be the second iteration of Sugar, hopefully using what we have
>>> learned during these years.
>>>
>>> This would mean that the next cycle would be devoted to rebasing on
>>> top of GNOME 3 so we remain packageable in future distros and that the
>>> next-gen activity APIs would only come afterwards.
>>>
>>> How does it sound?
>
> That is good with me, too.
>
>> I think that's a good plan. I would accept API cleanups (especially
>> deprecated API removals) if someone has time to do them though, I
>> would just not make it the focus for the release.
>
> I wanted to remove deprecated API already in 0.90, though people were
> screaming that it has not been announced early enough, which of course
> was fair enough.
>
> I think the important part is, that one has a policy for dropping and
> replacing API, communicates that and then as well move forward at some
> point do break and announce, remind and ping... Some people will switch
> in time others will need to hit the errors first, then move, but that is
> ok ;D

If we do our prep work in advance, we could hold a sprint to update
all of the activities (at least the ones in git) during a sprint. I
think it could be done quite quickly and efficiently.

> To give an example of how long API changes are accepted by activities
> the toolbars we introduced in 0.86 can be seen. I think probably 10% of
> activities has been ported so far. (no blame here, just observing)
>
> Regards,
>    Simon
>
>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-14 Thread Simon Schampijer
On 09/14/2010 01:33 PM, Walter Bender wrote:
> On Tue, Sep 14, 2010 at 7:18 AM, Simon Schampijer  wrote:
>> On 09/14/2010 11:08 AM, Marco Pesenti Gritti wrote:
>>> On Tue, Sep 14, 2010 at 9:26 AM, Tomeu Vizosowrote:
 One way of seeing things that might make more palatable 0.92 == 1.0 is
 that we are really still in the first iteration and 1.0 will be when
 that first iteration reaches maturity, without big changes in the API.
 After 1.0 we can start working on what will be one day 2.0 which
 should be the second iteration of Sugar, hopefully using what we have
 learned during these years.

 This would mean that the next cycle would be devoted to rebasing on
 top of GNOME 3 so we remain packageable in future distros and that the
 next-gen activity APIs would only come afterwards.

 How does it sound?
>>
>> That is good with me, too.
>>
>>> I think that's a good plan. I would accept API cleanups (especially
>>> deprecated API removals) if someone has time to do them though, I
>>> would just not make it the focus for the release.
>>
>> I wanted to remove deprecated API already in 0.90, though people were
>> screaming that it has not been announced early enough, which of course
>> was fair enough.
>>
>> I think the important part is, that one has a policy for dropping and
>> replacing API, communicates that and then as well move forward at some
>> point do break and announce, remind and ping... Some people will switch
>> in time others will need to hit the errors first, then move, but that is
>> ok ;D
>
> If we do our prep work in advance, we could hold a sprint to update
> all of the activities (at least the ones in git) during a sprint. I
> think it could be done quite quickly and efficiently.

Sure, that is why I think that communicating in advance and having a 
policy that everyone knows what to expect is the important part.

Regards,
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-14 Thread Simon Schampijer
On 09/14/2010 11:08 AM, Marco Pesenti Gritti wrote:
> On Tue, Sep 14, 2010 at 9:26 AM, Tomeu Vizoso  wrote:
>> One way of seeing things that might make more palatable 0.92 == 1.0 is
>> that we are really still in the first iteration and 1.0 will be when
>> that first iteration reaches maturity, without big changes in the API.
>> After 1.0 we can start working on what will be one day 2.0 which
>> should be the second iteration of Sugar, hopefully using what we have
>> learned during these years.
>>
>> This would mean that the next cycle would be devoted to rebasing on
>> top of GNOME 3 so we remain packageable in future distros and that the
>> next-gen activity APIs would only come afterwards.
>>
>> How does it sound?

That is good with me, too.

> I think that's a good plan. I would accept API cleanups (especially
> deprecated API removals) if someone has time to do them though, I
> would just not make it the focus for the release.

I wanted to remove deprecated API already in 0.90, though people were 
screaming that it has not been announced early enough, which of course 
was fair enough.

I think the important part is, that one has a policy for dropping and 
replacing API, communicates that and then as well move forward at some 
point do break and announce, remind and ping... Some people will switch 
in time others will need to hit the errors first, then move, but that is 
ok ;D

To give an example of how long API changes are accepted by activities 
the toolbars we introduced in 0.86 can be seen. I think probably 10% of 
activities has been ported so far. (no blame here, just observing)

Regards,
Simon




___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-14 Thread Simon Schampijer
On 09/13/2010 05:58 PM, Daniel Drake wrote:
> On 10 September 2010 13:41, Daniel Drake  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!

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

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

Regards,
Simon




___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-14 Thread Marco Pesenti Gritti
On Tue, Sep 14, 2010 at 9:26 AM, Tomeu Vizoso  wrote:
> One way of seeing things that might make more palatable 0.92 == 1.0 is
> that we are really still in the first iteration and 1.0 will be when
> that first iteration reaches maturity, without big changes in the API.
> After 1.0 we can start working on what will be one day 2.0 which
> should be the second iteration of Sugar, hopefully using what we have
> learned during these years.
>
> This would mean that the next cycle would be devoted to rebasing on
> top of GNOME 3 so we remain packageable in future distros and that the
> next-gen activity APIs would only come afterwards.
>
> How does it sound?

I think that's a good plan. I would accept API cleanups (especially
deprecated API removals) if someone has time to do them though, I
would just not make it the focus for the release.

Marco
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-14 Thread Tomeu Vizoso
On Mon, Sep 13, 2010 at 17:58, Daniel Drake  wrote:
> On 10 September 2010 13:41, Daniel Drake  wrote:
>> Just wanted to summarize an enlightening conversation that just
>> happened in #sugar:
>
> No responses..surprising!
> Let me try a bit harder then.
>
> My thoughts/suggestions:
>
> 1. Rename sugar-0.92 to Sugar-1.0
>
> 2. Switch to pygi and GTK+ 3 for sugar-1.0
>
> 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.
>
> 4. Ignore the silly people who draw large conclusions from looking at
> a version number
>
> 5. Publicise the fact that sugar-1.0 is an API break in all activities
>
> 6. If anyone had plans or specific goals for sugar-1.0 that won't be
> ready in time, push them off to sugar-2.0 (which can be released on
> the original timeline that people had thought for the original
> sugar-1.0)
>
> 7. switch to python3 at the same time? (ok, this one wasn't discussed,
> and I'm not sure of the realities, just something that crossed my
> mind!)

I'm not sure about the concrete advantages Python 3 brings, other than
remaining packageable once distros move to it, but J5 is porting
PyGObject to Python 3 and once we have dropped static bindings we'll
have a much easier path to it. OTOH, if 1.0 supports 2.7 and doesn't
use anything deprecated, the move to 3.0 would be smoother.

Regards,

Tomeu

> Daniel
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-14 Thread Tomeu Vizoso
On Mon, Sep 13, 2010 at 18:09, Marco Pesenti Gritti  wrote:
> On Mon, Sep 13, 2010 at 4:58 PM, Daniel Drake  wrote:
>> On 10 September 2010 13:41, Daniel Drake  wrote:
>>> Just wanted to summarize an enlightening conversation that just
>>> happened in #sugar:
>>
>> No responses..surprising!
>> Let me try a bit harder then.
>>
>> My thoughts/suggestions:
>>
>> 1. Rename sugar-0.92 to Sugar-1.0
>>
>> 2. Switch to pygi and GTK+ 3 for sugar-1.0
>>
>> 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.
>
> The time might be a bit short to do both porting and API changes. An
> alternative would be to have a longer unstable cycle (probably in
> parallel to a stable 0.92). I have the feeling that porting stable
> changes to unstable for a long time might be too much work for us
> though. So perhaps we really have to break API two times (1.0 and
> 2.0)...

One way of seeing things that might make more palatable 0.92 == 1.0 is
that we are really still in the first iteration and 1.0 will be when
that first iteration reaches maturity, without big changes in the API.
After 1.0 we can start working on what will be one day 2.0 which
should be the second iteration of Sugar, hopefully using what we have
learned during these years.

This would mean that the next cycle would be devoted to rebasing on
top of GNOME 3 so we remain packageable in future distros and that the
next-gen activity APIs would only come afterwards.

How does it sound?

Regards,

Tomeu

> Marco
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-13 Thread Marco Pesenti Gritti
On Mon, Sep 13, 2010 at 4:58 PM, Daniel Drake  wrote:
> On 10 September 2010 13:41, Daniel Drake  wrote:
>> Just wanted to summarize an enlightening conversation that just
>> happened in #sugar:
>
> No responses..surprising!
> Let me try a bit harder then.
>
> My thoughts/suggestions:
>
> 1. Rename sugar-0.92 to Sugar-1.0
>
> 2. Switch to pygi and GTK+ 3 for sugar-1.0
>
> 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.

The time might be a bit short to do both porting and API changes. An
alternative would be to have a longer unstable cycle (probably in
parallel to a stable 0.92). I have the feeling that porting stable
changes to unstable for a long time might be too much work for us
though. So perhaps we really have to break API two times (1.0 and
2.0)...

Marco
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar and activities flag day

2010-09-13 Thread Daniel Drake
On 10 September 2010 13:41, Daniel Drake  wrote:
> Just wanted to summarize an enlightening conversation that just
> happened in #sugar:

No responses..surprising!
Let me try a bit harder then.

My thoughts/suggestions:

1. Rename sugar-0.92 to Sugar-1.0

2. Switch to pygi and GTK+ 3 for sugar-1.0

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.

4. Ignore the silly people who draw large conclusions from looking at
a version number

5. Publicise the fact that sugar-1.0 is an API break in all activities

6. If anyone had plans or specific goals for sugar-1.0 that won't be
ready in time, push them off to sugar-2.0 (which can be released on
the original timeline that people had thought for the original
sugar-1.0)

7. switch to python3 at the same time? (ok, this one wasn't discussed,
and I'm not sure of the realities, just something that crossed my
mind!)

Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


[Sugar-devel] Sugar and activities flag day

2010-09-10 Thread Daniel Drake
Just wanted to summarize an enlightening conversation that just
happened in #sugar:

1. GNOME 3 is expected to be released 6 months after GNOME-2.32. This
roughly lines up with the release date for Sugar-0.92.

2. GNOME 3 is expected to be based on GTK+-3, which breaks
compatibility with GTK2 (but can presumably be installed side-by-side
with GTK2, like GTK2 can coexist with GTK1)

3. Programs cant use GTK2 and GTK3 at the same time. One or the other.

4. PyGTK (used extensively by Sugar and activities) is not expected to
be ported for GNOME-3.

5. pygi ("gobject introspection") is the effective replacement for
PyGTK but requires a truckload of trivial changes to every
program/module that uses PyGTK (see
http://live.gnome.org/PyGObject/IntrospectionPorting)

6. We'll also see problems where (e.g.) evince moves to GTK3, meaning
that we lose the static Python bindings and are expected to switch to
gobject introspection. The Read activity would then have to start
using pygi+GTK3, but it can't do that because the Sugar GUI libraries
which it uses use GTK2, and we arrive at point #3.

7. It is likely that distributions that ship GNOME-3 will start
shipping pygi and stop shipping PyGTK (or ship a PyGTK with
substantially reduced API), meaning that sugar and all activities will
simply *stop working*



This obviously calls for Sugar switching to GTK3 and remaining in sync
with gnome, but will be a big headache w.r.t. activities.

Some ideas that were thrown around:

- Someone could write a compatibility layer that makes code written
for pygi work with PyGTK (therefore we port the whole of the sugar
world, but people can install the compat layer and keep it running
with GTK2)
 ... but this would be a huge amount of work, and the time would be
better spent on the work needed to bring sugar up-to-date

- When making the switch we could bump sugar's version number to 1.0
in order to make the change really obvious
 ... but there are concerns about false implications that people would
draw from such a number ("Sugar is mature!!")
 ... some people would want to use such a version jump to make
backwards-incompatible changes in the Sugar API and those people would
probably want more than 6 months in order to prepare for it

- or we could just bump it to sugar-0.100, but thats not such a strong
communication (under the current 6-month system we'd reach sugar-0.100
in 2.5 years time without breaking API)


Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel