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. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
