Re: Creation of a new roadmap for GNOME

[Brian Cameron <Brian Cameron Sun COM>]

Vincent:

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

It might be good to be a bit specific in the questionnaire about
Platform versus Desktop roadmap issues.  Since the Platform is special
it might be good to try and get people to think more about the future
direction of the Platform, in addition to just general ideas about
\GNOME's future.

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

Yes, it would be nice to get some traction on some of these higher-level
issues.  I think the RoadMap process could be used to help facilitate
discussion on these sorts of questions.

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

I'm not suggesting the GNOME community should break API/ABI at all.
I just think that the GNOME community isn't very clear about which
Platform Libraries should be used going forward and which ones are
maintained just for backwards compatibility.  If I'm a new
user/developer/ISV/whatever, then how do I know which Platform libraries
I should focus on using?  I don't think the GNOME community is very
clear about this today.

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

I think I'm just suggesting that we think more about what barriers
might prevent people from considering the GNOME desktop seriously as
an integration platform.  What sorts of things would cause a 3rd party
to think, "well if I can't do that, this desktop really isn't mature
enough for what I want to do".

In Windows, for example, you end up with all sorts of crufty little
background programs in your panel that slow down your CPU.  Would it
turn away some ISV's if they can't do the same thing in GNOME, or is
a feature that we protect your CPU by not providing this feature?  :)
I also note some programs like Rhythmbox install similar widgitry
things in your panel when they run.  Do we want these sorts of
interfaces exposed and supported to users outside of the GNOME
project?  Likewise with the notification daemon.  If we want 3rd
parties to use it, should the interfaces be a part of the Platform?
Questions like this.

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

I think any attention made to improving the Platform and making it more
clear to end-users what they should use, and how, is a part of improving
interface stability.  So, if the RoadMap helps in this area, then I
think it is (in some way) a part of the process.

But this is just my thinking.

Brian