Re: Creation of a new roadmap for GNOME

[Vincent Untz <vuntz gnome org>]

Hi Brian,

Le mercredi 04 avril 2007, à 15:35, Brian Cameron a écrit :
> 
> Vincent:
> 
> > There have been some discussions in the past few weeks on how to improve
> > the GNOME roadmap. The result of those discussions is a new process to
> > create and maintain a GNOME-wide roadmap.
> 
> If we are going to keep closer track of a GNOME RoadMap, then wouldn't
> it also make sense to keep track of ongoing RoadMap issues such as
> Project Ridley?

Yes. This is something that should be part of the roadmap, I believe.

>    http://live.gnome.org/ProjectRidley?highlight=%28projectridley%29
> 
> Project Ridley is basically an effort to improve overall interface
> stability, by moving important interfaces from the Desktop into the
> Platform and cleaning up the Platform so that fewer libraries are
> needed to write a reasonable GNOME application.  Also what about
> other related ideas that I've seen talked about, like replacing
> libart_lgpl with cairo?  I know the GNOME team has done a lot of work
> implementing Project Ridley, but are the current plans still accurately
> represented on the Project Ridley website?

The fact that the Project Ridley page might be outdated is one of the
reasons why we're trying to have a new process to periodically update
the roadmap.

Replacing libart_lgpl with cairo is a good example of something you
should suggest to the roadmap gang when you'll get the mail asking about
your plans and ideas. This is something that sounds good, but we just
need to coordinate ourselves (and we hope the new roadmap will help with
this).

> I'd think there are other interface stability issues that should also
> be tracked in our RoadMap.  For example, how are end users supposed
> to integrate with various FreeDesktop specifications.  Should people
> be encouraged to use Portland interfaces or gtk-update-icon-cache,
> update-desktop-database, and update-mime-database?
> 
>    http://portland.freedesktop.org/wiki/

My personal opinion is that we should directly use
gtk-update-icon-cache, etc. But again, this is something high-level that
could be raised as part of the roadmap process. We can use this process
to identify open questions and get answers to them.

> Are there any plans to expand the GNOME Platform to include any
> libraries that are needed to write a reasonable GNOME application?
> Or will the Platform shrink to remove no-longer-needed libraries
> such as libgnome?  I don't think there has been any real discussion
> about what we're doing in this area for a while, so it might be
> worth some discussion.

As long as we keep our API/ABI stability, we can't remove libraries from
our platform. Therefore, the first question would then be: do we want to
break API/ABI? My understanding was that it's really something we want
to avoid. Of course, we can always discuss this if there are strong
arguments to break API/ABI.

Knowing what parts are missing from our platform is definitely something
that we hope we'll get through this process, and so we'll know if and
where we need to expand the platform.

> It would be nice to perhaps identify what interfaces the GNOME desktop
> should provide to end-users which are not currently provided.  For
> example, there is no stable/recommended interface for adding applets to
> the panel, or shortcuts to the desktop.  Are there features like this
> that should be considered in a RoadMap?

In the roadmap process, yes. I can't tell you this is the kind of stuff
that might be in the roadmap document at the end of the process, though:
what you're proposing here is too detailed for a GNOME-wide roadmap (but
it could be perfect for the panel and nautilus roadmaps). It could be
good for the GNOME-wide roadmap if you say "be friendly to ISD/ISV who
want to nicely integrate", which is something a bit more general.

> Since improving interface stability is an ongoing effort, it seems
> a RoadMap is a good place to keep track of how far along we are, and
> where we hope to go.  Though, perhaps this is out of scope of what
> you are planning to do with this.

It's definitely something that the roadmap can help with. I'm not sure
this should be done within the roadmap process, but it can rely on the
roadmap process.

> > More details about how this process will work are available at:
> >   http://live.gnome.org/RoadMap/Process
> > 
> > In the next few days, all maintainers will receive a mail asking them
> > some questions about their plans for the modules they're maintaining.
> > It's really important that maintainers take the time to correctly reply
> > to this mail. A new team (the Roadmap Gang) will analyse all the
> > replies, and try to keep only the relevant parts for a GNOME-wide
> > roadmap.
>  >
> > Not only will we get a roadmap, but this will also help highlight some
> > of our goals, which should make it easier to know where to put some of
> > our efforts and what is the direction of our development.
> > 
> > This will also give us roadmaps for each of our modules: this will
> > hopefully help new contributors know where they can help.
> 
> Would it make sense to make use of bugzilla to tag (perhaps with a
> keyword) those issues that correspond to the RoadMap, so people could
> easily find where help is most needed by just using a bugzilla search
> or look at a report showing them sorted with priorities?

It might make sense. This is still a work in progress, so we don't know
how everything will work :-)

> > If you're interested in helping with this process, please contact Lucas
> > and me: we need a few more people in the Roadmap Gang. There's no need
> > to be a huge contributor, so don't hesitate to step up: only some free
> > time is required :-)
> 
> I'd be interested in being involved.

Cool!

Vincent

-- 
Les gens heureux ne sont pas pressés.