[IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)

[Peter Robinson]

On Sat, Apr 17, 2010 at 2:52 AM, Bernie Innocenti <bernie at codewiz.org> wrote:
> On Fri, 2010-04-16 at 23:31 +0100, Peter Robinson wrote:
>
> [...]
>
>> > I'm not against packaging Sugar for RHEL. I just think it would cost
>> > more to support after the first year or two.
>>
>> Agreed. And in fact I said that exactly and hence my reference to the
>> 18 month to 2.5 year point but the fact is by then you'll almost be to
>> RHEL N+1 release so you role it over.
>
> Oh, now I get it. And I think I agree with you.
>
>
>> The EL packaging makes it easy enough that its "if it compile and
>> there is demand for it then you can do so because to push it out isn't
>> had" if it stops compiling you send it out to the lists and either
>> people care enough to fix the problem or else it stays on what ever
>> the currently compiling version is. Sort of like the extended
>> maintenance of the 0.84.x releases.
>
> Agreed here too (we're on the good way).
>
>
>> Your making the problem like a Cross Road in a road. Its really not
>> that. We are going to be following the upstream Fedora releases but I
>> really don't think it will be hard to follow a RHEL release train
>> either. In the F-7 to F-10 time frame the changes were massive. I know
>> I had to assist in merging them upstream. But since then there's not
>> been massive underlying changes that aren't manageable. The biggest I
>> think are probably Tomeu's plans for the telepathy stuff and that is
>> just to bring us back in line with the main line.
>
> I really hope you're wrong, but I'm afraid you're correct. We'd still
> have to change so much before Sugar becomes as mature and usable as
> Gnome is nowadays.
>
> Besides toemu's rewrite of the collaboration stack, there's Sascha's
> rewrite of the datastore still in the works.

Yes, but I suspect that's more an internal change to the underlying
structure and design rather than something that is going to require
the latest and greatest library version X that's not released yet.

>> I think the next big disruptive change will be python3 and associated
>> pygtk changes, and while I don't have a crystal ball I think we can
>> either stick with the current and it will be supported or there will
>> be ways to support the new stuff.
>
> I'm not looking forward for Python 3. Every other large Python project
> has been procrastinating on this transition because there's not much to
> gain and a lot to loose.

Yes, but its starting to pick momentum now. The first 3.x release is
out fixing up some of the issues. Fedora 13 will have a python3
package and the python hack fest hosted at OLPC's office to bring up
the gnome python bindings in preparation for gnome 3 also had quite a
focus on support for python3 too,

> For us, switching to Python 3 would be unthinkably disruptive: half of
> the activities would remain broken for years, unless we maintain a
> Python 2 stack for backwards compatibility... /me shrugs

And there is a perfect reason for a stable distro such as RHEL or CentOS :-)

Peter