Skip navigation.
home | news feeds | archives | search | forums | submit news
Home » view

Planning for GNOME 3.0

Submitted by stro on Sun, 2009-04-05 20:00. GNOME
GNOME

From GNOME mailing lists.....

During the first few months of 2008, a few Release Team members
discussed here and there about the state of GNOME. This was nothing
official, and it could actually have been considered as some friends
talking together about things they deeply care about. There were
thoughts that GNOME could stay with the 2.x branch for a very long time
given our solid development methods, but that it was not the future that
our community wants to see happening. Because of lack of excitement.
Because of lack of vision. Slowly, a plan started to emerge. It evolved,
changed, was trimmed a bit, made more solid. We started discussing with
a few more people, got more feedback. And then, at GUADEC, the Release
Team proposed an initial plan to the community that would lead the
project to GNOME 3.0. Quite some time passed; actually, too much time
passed because too many people were busy with other things. But it's
never too late to do the right thing, so let's really be serious about
GNOME 3.0 now!

Let's first diverge a bit and discuss the general impression that GNOME
is lacking a vision. If you look closely at our community, it'd be wrong
to say that people are lacking a vision; but the project as a whole does
indeed have this issue. What we are missing is people blessing one
specific vision and making it official, giving goals to the community so
we can all work together in the same direction. In the pre-2.x days, the
community accepted as a whole one specific vision, and such an explicit
blessing wasn't needed. But during the 2.x cycle, with our six months
schedules, it appeared that everything (community, development process,
etc.) was just working very well, and as the vision got more and more
fulfilled, the long-term plans became less important as we focused on
polishing our desktop. But we've now reached a point where our next
steps should be moving to another level, and those next steps require
important decisions. This is part of what the Release Team should do.
Please note that Release Team members don't have to be the ones who have
the vision; we "just" have to be the voice of the community.

(As a sidenote, the roadmap process [1] that we tried to re-establish
two years ago was a first attempt to fix this. Unfortunately, it turned
out that we were missing the most important side of things: a
project-wide roadmap. This is because a collection of individual
roadmaps isn't enough to create a project-wide roadmap.)

So let's go to the core topic and discuss what the GNOME 3.0 effort
should be. We propose the following list of areas to focus our efforts
on:

- Revamp our User Experience
- Streamlining of the Platform
- Promotion of GNOME

There are also other potential areas that are worth exploring if there
is enough interest from the community.

GNOME 3.0 Schedule draft; Streamlining of the Platform.

a draft for the GNOME 2.27 & 2.29 schedule is now available at

http://live.gnome.org/TwoPointTwentyseven .

The schedule also includes a plan to clean up the platform by getting
rid of deprecated modules.
Maintainers can see the GNOME 3 readiness of their modules on Frederic's
awesome status page at http://www.gnome.org/~fpeters/299.html .
Comments & discussion welcome.

Notes:
* 2.30.0 is planned to be 3.0.0, if the QA agrees (For a general
GNOME 3 debate, please see other threads like Vincent's recent
posting at
http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg00004.html and http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg00005.html ). I don't plan to cover everything+1 in this schedule, it's just that I concentrated on platform streamlining.)
* Only two maintenance releases for 2.28.x
* Early module freeze for 2.30
* More & earlier 2.29.x releases than normally (better testing)
* Two weeks hardcode freeze before 2.30.0 - late release at the
last day of march 2010
* Still to discuss: dconf vs gconf. This is not yet covered by
this plan, but crucial to discuss (as gconf depends on Bonobo) -
robtaylor and/or desrt will probably elaborate its current
state.
* Still to discuss: a11y plan for GNOME3 - see
http://live.gnome.org/Accessibility/BonoboDeprecation

Already know some 2.28 plans for the module you maintain?
Add them to http://live.gnome.org/RoadMap now!

QA Issue - Planner in Gnome 3 ?

Submitted by Anonymous George (not verified) on Thu, 2009-04-16 16:25.

It is well known that the Planner application has a fault in that it does not do resource levelling

http://bugzilla.gnome.org/show_bug.cgi?id=132917

This is unfortunate because it means that Planner can't be used for computing a project plan. Without wishing to dishearten anyone but being brutally honest this makes Planner useless as a project planning tool.

Now libplanner is part of Gnome and is integrated into the desktop so that Gnome 2 ships with a broken Planner application that doesn't really work but is integral to the platform.

My argument is that this issue and any others like it should be resolved in Gnome 2 before Gnome 3.0 is released. If not, the broken status of components is being tacitly accepted. If Gnome 3 is intended to provide an improved user experience this should surely include mending that which is broken in Gnome 2.

There is a large payoff here. An integrated Planner that works would have profound implications for the uptake of Gnome in workplace environments. Furthermore, a solution to resource levelling would likely require a linear optimiser such as the GLPK. Inclusion of such an LP solver in Gnome 3 would create new opportunities for developers and potentially allow a lot of redundancy to be removed from Gnome.

To summarise :
Gnome 3 should not inherit broken components from Gnome 2 - these issues should be resolved first.
Gnome 3 should include a single solution for linear optimisation.
Any other long-standing major shortcomings of Gnome 2 components should be addressed prior to the release of Gnome 3.

Jon Guiton

» parent