Re: GNOME: lack of strategic roadmap

[Philip Van Hoof <pvanhoof gnome org>]

On Tue, 2010-02-23 at 16:53 +0000, Martyn Russell wrote:

Hi Martyn,

Don't be confused: most of this reply isn't directed at you personally.

> On 23/02/10 16:09, Dodji Seketeli wrote:
> > Le mar. 23 févr. 2010 à 14:12:47 (+0000), Martyn Russell a écrit:
> >> Actually, I think that the Red Hat maintainers of the toolkit had an
> >> interest in stability (for ISVs) and that stifled development. As
> >> such developing anything in GTK+ takes a lot longer than it should
> >> and that's why it is always hard to get into development there or to
> >> fix something. This has long been the internal politic of GTK+.
> >
> > Wasn't it possible to develop the new things in branches to showcase
> > your ideas and tell the world about those new features?
> 
> Yes and it still is, see the MPX branch, the GSEAL work was also started 
> in a branch and many things are done that way.
> 
> > Just to make things clear, this is a real question, not an attempt to
> > point finger or anything like that.
> >
> > I am asking because, even in layers like X.org where compatibility is
> > key, trying things in branches and showing the world proved to have
> > worked quite well.
> 
> When talking to some of the core maintainers, they often say they want 
> to refactor things internally in GTK+ to make maintaining it easier and 
> getting new people into the toolkit easier.

What are we waiting for? The Gods? Ideology?

Let's be serious..

> Just today on #gnome-hackers, I saw someone interested in getting
> into GTK+ development and he said it was really hard. I agree.

I agree with this person too. It is extraordinary hard: that's not good.

Not at all.

> Johannes makes a really good point too. At some point you could probably 
> say that GTK+ was _THE_ exciting project to work on and a lot of code 
> got in that should have had more reviews and perhaps that's why it needs 
> cleaning up in places now.

Comon! How many years of cleaning up does a team need unless it admits
that its entire architecture was one big design flaw?

I don't believe that GTK+ needs more cleaning up. Its architecture isn't
that flawed at all.

Let's not be childish and let's be honest about our technology; its
future.

Not even a mission to the moon ever needed as much years of cleaning up
as GTK+ seems to need if you do follow the logic that the GSEAL work is
the only big thing a group can do within a year.

I think it's untrue to say that GTK+ needs more years of cleanups before
it can start receiving innovation.

Let's stop being children. No matter how impolite my statements are.

> GTK+ has also been too exposed to change some of these issues (hence
> the GSEAL work).

I applaud the GSEAL work. It just hasn't been enough for a year or more
of work on GTK+: no matter how you look at it, GTK+'s innovation is
stalled. To the point that it gets ridiculous.

If that statement takes all of my karma, whatever karma means, then it
does. So be it.



Cheers,


Philip



-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be