Release Team Interview for the GNOME 2009 Annual Report
Format
For questions and answers, please try to add them in this format:
Question:
- (Name of person answering) Answer
Interview Questions
- Who are the members of the Release Team?
- Vincent: We're nine people as of today: Andre Klapper, Frédéric Crozat, Frédéric Péters, Karsten Bräckelmann, Kjartan Maraas, Lucas Rocha, Matthias Clasen, Olav Vitters and me. There is something worth pointing out: if you look closely, you'll see that we are three native French speakers, and Andre also speaks French fluently. I guess we're nearing our goal to switch GNOME to French by default! On a more serious note, it's great to see that we have people coming from different horizons: in this team, we have people who work or have worked on code (platform and desktop), bug triage, localization or infrastructure. This is definitely something that we value since our role sometimes requires balancing between conflicting needs from different teams, and understanding the other teams is important in such cases.
- What is the role of the GNOME Release Team?
- Andre: First of all, we of course publish GNOME releases after testing if the tarballs provided by the module maintainers compile and work together. Twice a year we make the final decision on new modules (or external dependencies) after a module maintainer has proposed his/her module for official inclusion into GNOME and collecting input and feedback by the community on it, trying to enforce consensus on proposals if possible. We come up with the release schedules and keep everyone informed about the various stages we are in, and sometimes we also have to nag to get some stuff fixed. Also we push GNOME-wide goals, like currently cleaning up for GNOME 3 by not using deprecated functionality of the GNOME 2 platform anymore and hence urging developers to port their modules, and we try to ensure that release notes are written though we've sometimes been bad with that in the past.
- GNOME 2.0 was released in June, 2002. How has the release team helped coordinate 6 month releases of GNOME 2.x years? What has worked well? What hasn't?
- Andre: Having a time-based schedule with clear periods and freezes instead of a feature-based one helps developers to focus, for example to stabilize the software at the end of a cycle instead of hacking on new features. String Freeze and UI Freeze help translators and documentation writers by making sure that no updates to their work are required again in the release cycle. Also, the time-based schedule makes planning easier for distributors. If module maintainers work on complex tasks that take longer than six months to get finished this can be done in a branch in the repository of their module that later on gets merged again. Of course there have been a few adjustments to the release schedule over the time - the latest one was to have the module proposal period two months earlier in the release cycle so that maintainers of proposed modules have more time to consider and implement the community feedback and to integrate their module successfully into the GNOME stack.
In April 2009, Vincent Untz, on behalf of the Release Team, sent an email to the GNOME Desktop Development mailing list to start the GNOME 3.0 discussion.
- What led up to this email?
- Olav: Exactly what is stated within the email. A few release team members discussed the state of GNOME privately. A while later various release team members were at the same conference. We used that opportunity to further discuss and come up with some wishes we had. After it became concrete enough to be written down it was discussed with the whole team. The discussion continued on until we met at GUADEC 2008, where we announced our plan.
- Vincent: The funny thing there is that a few of us were independently thinking around the same lines and we realized this at the beginning of 2008, when discussing about the future of GNOME. We arrived in Istanbul with a rough idea of where we wanted GNOME to head and this is where we prepared some slides to introduce our ideas to the community (remember the "2.30 = 3.0"?). The goal was really to just plant the seeds that would push contributors to think about 3.0. We let some time go after GUADEC to listen to feedback and to see the various new ideas that started appearing in the following months. But we felt that it was necessary to consolidate a plan for 3.0, to create a focus in the community; this resulted in the mail you mentioned.
- In your opinion(s), what were the results within the community of having this discussion?
- Andre: Version 3 had been mentioned from time to time over the years, often in combination with vague ideas or proposals for complex changes of huge parts of the existing system. When there is no concrete proposal available it is easy to end up in endless discussions that turn into bikeshedding and no actual work being done. The idea of GNOME3 was initially announced by the release-team at GUADEC 2008 to give the community an option to discuss the proposal directly at the conference with each other, face to face. This helped creating some momentum to reflect on GNOME wide changes and a vision instead of everybody just having her/his own project in mind. Still the mission of GNOME 3 was not very clear as this was just a proposal, resulting in some uncertainty both in the community and GNOME's userbase. The email in April 2009 was in order to provide a better basis for the forward progress, to receive legitimation on the plan, to define where to focus so that the GNOME community has clear goals set, and also to reduce existing doubts.
- What led up to this email?
- GNOME 2.32, scheduled for September 2010, is to become GNOME 3.0. What were the considerations for picking this particular release?
- Andre: At GUADEC 2008, we proposed to target GNOME 2.30 to become 3.0 and wanted the community to start discussing plans and ideas. I think that this is always easier plus more realistic when having a specific deadline in mind that is not too far away. However we always stated that this date was not written in stone and that a final decision on the 3.0 release date would be made in October 2009, and after asking for feedback from several teams in terms of quality and accessibility it became clear that waiting six more months and having another release (2.30) on our way to GNOME 3.0 will ensure that 3.0 will become the quality release that our users and customers expect.
Vincent: Andre explained it fine, but he forgot one essential part: gambling
- What can users expect in GNOME 3.0?
- Vincent: The most visible change for users is GNOME Shell. This is the new core part of the desktop, that we've redesigned in an innovative approach, keeping the goal of providing an intuitive interface, with a small learning curve. One goal of the GNOME Shell design is to make it as non-intrusive as possible, to let the users focus on their real work. Good examples of this are the way notifications are handled or the new symbolic icons used to display the system status. But the most visible change brought by GNOME Shell is the overview mode, which is the central piece of the shell where you switch between activities -- activities that are already running or new activities -- and we want to help users organize their activities by simplifying the use of virtual desktops.
To get a real feeling of how well it all works, you have to try it, though
We also want to talk more about applications: we have a rich ecosystem of GNOME applications, but we feel everybody talks about GNOME as a whole and it's sometimes too hard for application writers to promote their application if they're not officially part of GNOME. We want to help them here, and we want the world to know how great all the applications in our ecosystem are.
Another visible change is the work on the accessibility stack, which has been rewritten to use D-Bus instead of CORBA. In concrete terms, this means that the KDE Desktop will be able to use our accessibility stack, which will help make KDE accessible (we're proud to contribute to this!) but also will make it possible to use non-GNOME applications in GNOME in an accessible way. We also have various other projects going on in the accessibility world, like a head-tracking system based on webcams to control the mouse cursor or improved access to PDF contents.
Finally, I believe it's worth pointing out that GNOME 3.0 is not a destination: it's just the beginning of a new journey for the GNOME community, and the GNOME 3 effort will keep bringing new and innovative features as well as bug fixes in the forthcoming years. I like to write "GNOME 3.0 ≠ GNOME 3" to explain this, and a really good way to think of this is to think about GNOME 2.0 and GNOME 2.30: when we started the GNOME 2 effort, we had GNOME 2.0 which was fantastic back then, but I'm fairly sure nobody would go back from 2.30 to 2.0 And we already know users can expect great new changes in GNOME 3 after 3.0. For example, our designers have been working hard on some new designs for Nautilus (our file manager), and more generally, we want to redefine the way people access and manage their documents. Another example is the integration with all the online world, which we expect to improve. GNOME 3.0 is the first step towards bigger changes!
- What can developers expect in GNOME 3.0?
- Andre: A cleaner and smaller platform that has dropped lots of its ballast from the last eight years, like for example bonobo, esound, gnome-vfs, libart_lgpl, libglade, libgnomeprint, libgnome and libgnomeui.
- Vincent: Andre mentioned cleaning up the platform, but we'd also like to clarify our message to developers. While we offer bindings of high quality, they're not part of our platform, so some people might feel that C is still the preferred language for GNOME; but the C++ and Python bindings are really amazing, and Javascript is emerging as a new first-class language in the GNOME world. Also, our platform is limited to a set of modules that are maintained by GNOME or close to GNOME (like GTK+) and that offer guarantees of API and ABI stability. This excludes some libraries that should really be used by developers, but that aren't part of our platform. Take D-Bus and GStreamer for example: right now, D-Bus is only a external dependency, and GStreamer does not offer the API/ABI guarantees and therefore is only in the desktop moduleset. But both provide solutions that we recommend to developers, and so should be advertised as part of the platform.
- What work remains for the GNOME 3.0 release?
- Andre: The deprecated Bonobo component is still used by our current accessibility tools and by the gnome-panel, forcing several other modules providing panel applets to also depend on Bonobo, but according to rumours Vincent is working on the latter part. Porting and partially rewriting GNOME's accessibility framework and tools is ongoing and on a good way thanks to Willie Walker and others, but still a huge and complex task. Especially Caribou which might replace gok needs more manpower, so if some Python hackers are interested... Work to port modules from using gconf (GNOME's registry) to dconf/GSettings has not started as the required GSettings and GVariant are not yet in GTK+/Glib. The underlying GTK+ toolkit still receives deprecations in the field of sealing in order to not expose internal implementations. Besides, several options for the future of the Python bindings for GNOME 3 are currently being discussed. With regard to GNOME Shell and GNOME Journal/Zeitgeist I also assume that more accessibility testing is very welcome.
- Vincent: Carlos Garcia Campos did the initial work to get rid of bonobo in the GNOME Panel, so it will definitely happen!
- What are you most excited about in GNOME 3.0?
Andre: The corresponding release party.
Vincent: I really like GNOME Shell: it enables us to move in new directions. And also, it will mean GNOME Panel will finally start disappearing (although it will still be maintained for some time, for people who cannot run the Shell)
- When is GNOME 4.0 scheduled? (I'm just kidding - trying to see if you're paying attention!)
- Andre: GNOME 2 was released in 2002 and GNOME 4 will surely happen before 2018, but I don't dare to forecast the development of the GNOME platform and also the related "Desktop" metapher in the next years.
- Vincent: Actually, when planning for 3.0, we discussed doing what we called "long-term development cycles", which would be a way to set long-term goals for GNOME that might not be achievable in a 6 months timeframe. And we thought that a period of around 3 years would be appropriate. Maybe this could be the basis for a 4.0 planning... What I know for sure is that we shouldn't be afraid of starting to think about doing 4.0, while still offering great 3.x releases where we'll keep delivering more GNOME 3 awesomeness!