Re: GNOME: lack of strategic roadmap

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

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.



Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]