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

[Bernie Innocenti]

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.


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

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

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/