Re: GNOME: lack of strategic roadmap
- From: Martyn Russell <martyn lanedo com>
- To: Philip Van Hoof <pvanhoof gnome org>
- Cc: Dodji Seketeli <dodji seketeli org>, foundation-list <foundation-list gnome org>
- Subject: Re: GNOME: lack of strategic roadmap
- Date: Wed, 24 Feb 2010 09:03:36 +0000
On 23/02/10 22:52, Philip Van Hoof wrote:
On Tue, 2010-02-23 at 16:53 +0000, Martyn Russell wrote:
Don't be confused: most of this reply isn't directed at you personally.
Sure, but I will indulge all the same ;)
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..
We aren't waiting for anything :) But you can't refactor exposed public
struct pointers which are in common use since you break the API and any
application using that structure. The GSEAL work is an initial step to
make this refactoring process easier.
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?
It's not really that. Every project requires constant maintenance to
change with the times. If you only build on top of what was already
there, then at some point, the architecture and parts of the code base
need rethinking to make the toolkit maintainable and optimal. This is
true in any project that survives time and innovation.
I don't believe that GTK+ needs more cleaning up. Its architecture isn't
that flawed at all.
But that's your opinion as someone who is not and has not been a
maintainer. Talking to the maintainers is actually how I formulated my
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 NASA had a lot more people working for them than the GTK+
project and the GSEAL work is quite comprehensive. At one point Imendio
labs time (1/2 a day per week) was used by the whole company for some
months to JUST do sealing and we are still not quite done.
I think it's untrue to say that GTK+ needs more years of cleanups before
it can start receiving innovation.
Innovation can always be done, but if each time you want to do it you
really want to refactor the code base before you start, that dampens
your efforts and costs time to work around.
Tracker is no different here. It has had a lot of clean ups before it
started getting any innovation.
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.
At some point you have to clean up your code base, that's been the case
in every project I have worked on. I don't think it is a bad thing that
GTK+ is released just "more cleaned up", but others disagree and want
3.0 to have x, y and z major new features.
If that statement takes all of my karma, whatever karma means, then it
does. So be it.
] [Thread Prev