Meeting minutes (April 10th)


Note that we didn't discuss the old action items. I removed some of them
that were obvious, and left the ones where I was unsure.



 Andre Klapper (andre)
 Frederic Crozat (fcrozat)
 Frederic Peters (fpeters)
 Lucas Rocha (lucasr)
 Matthias Clasen (mclasen)
 Vincent Untz (vuntz) -- taking minutes

 Olav Vitters (bkor)

 Kjartan Maraas (kmaraas)
 Karsten Bräckelmann (guenther)

 + team changes
 + 2.30 feedback
 + release assignments
 + moduleset reorganization
 + GNOME 3 status
 + AOB


New actions:

 + send an announcement to the community about the moduleset
   reorganization before the new modules decision.

 + chat with the accessibility team about getting one accessibility
   person on the release team.
 + send a mail to d-a-l to remind maintainers about a few things to
   make our releases smoother.

Those are the old actions, we forgot to discuss them, so I'm putting
them here for reference and discussion:

Frederic P.:
 + push for a decision for a solution for deprecations in bindings

 + PENDING: setup initial wiki page for 3.0 roadmap
 + PENDING: maybe announce the roadmap process change for 2.28 & 3.0
 + push for a "web services" set of libraries

 + check the wiki pages
 + ONGOING: contact the GNOME Foundation about the clutter copyright
   waiver and copyright assignment

Team changes

There's been discussion about having someone from the accessibility team
join the release team, and we like this.

Vincent will leave the team after the release of 3.0. Andre and Frédéric
(Crozat) are considering leaving too. However, we can't let too many
people leave at the same time, to make sure knowledge is passed to new
members and exprience is not lost.

Matthias suggests to contact the GNOME Shell people for potential new

People who will leave the team should come with a few names for new
members to replace them.

ACTION: Vincent will chat with the accessibility team to find out how to
        move on this.

2.30 feedback

We had to request too many tarballs, and we rolled ourselves many
tarballs while maintainers could have helped. Some of those tarballs
contained late changes (or old code that never made it into a release)
with serious bugs.

API deprecations caused various issues, especially with building
tarballs that are hard-coded to build without deprecated API.

The first gnome-icon-theme release came late, and broke various things
because of missing icons. This should have been done earlier, and the
list of removed icons should have been communicated better.

Some maintainers forget to commit and push the changes after a release,
or to tag the release.

Things to change:
 + instead of making sure we have new tarballs for all modules for the
   .0 release, we should do this for the .90 release.

 + maintainers should stop hard-coding the deprecation flags in

 + maintainers should not forget to push and tag a release.

 + communicate about changes impacting other modules.

ACTION: Vincent to send a mail to d-a-l to remind maintainers about all

Release assignments

Apr 28 2.30.1  fredp
May 05 2.31.1  mclasen
May 26 2.31.2  vuntz
Jun 09 2.31.3  lucasr
Jun 23 2.30.2  vuntz
Jun 30 2.31.4  mclasen
Jul 14 2.31.5  lucasr
Aug 04 2.31.6  vuntz
Aug 18 2.31.90 fredp
Sep 01 2.31.91 fcrozat
Sep 15 2.31.92
Sep 29 3.0.0

If somebody wants to do one release and replace someone, please mail the

Moduleset reorganization

We worked on various proposals for this
(, but the key ideas
we want to implement are:

 + split the desktop set in two: the core desktop and the applications.
   Over the years, the desktop has grown a lot and to a point where it's
   unclear why an application is in there while another is not.
   There is no clear definition of exactly how this split will be done,
   but one criteria that can help decide if whether a module has a brand
   or not. People from the user experience team, as well as maintainers,
   should help with the split.

 + improve the platform:
   - we want to make the bindings first-class citizen of our platform
     (having them in a separate moduleset is not the best way to promote
   - we want to include in the platform some external dependencies
     (dbus, upower, etc.). From a release management point of view, this
     can be something that has no real impact on our work (since the
     tarballs are not hosted on, but it's important from
     a communication perspective.
   - we want to clarify that some libraries should be used by developers
     even if the API/ABI guarantees are not as strong as our GNOME 2
     platform (for example: GStreamer, e-d-s) -- such libraries should
     be labeled as such, obviously.

Being part of the core desktop could also lead to some differences for
modules: branding should be reduced, about dialogs could be removed,

We might need to categorize/tag applications in the Applications
moduleset in the long term, to help users. Using the Categories key from
their .desktop file is a potential solution.

This all needs to be well-explained so people understand the proposal on
first read :-)

ACTION: Lucas will send an announcement to the community before the new
        modules decision.

GNOME 3 status

 + GVariant has landed in 2.30.

 + gdbus is moving again and should land this cycle.

 + The plans around GSettings and dconf will be clarified during the

 + We need maintainers to take a few days to finish the cleanup (mostly
   GSeal now, but dconf port might be next). A few more specific notes:
   - libgnomecanvas: evolution is left; it's two days of work; should be
   - libglade: sound-juicer is left; patch available.
   - libgnomeui: done.
   - libgnome: gnome-applets & tomboy are left.
   - gnome-print: done.
   - gnome-vfs: done.
   - single includes: mostly done.
   - bonobo: gconf, gnome-panel, accessibility are left; there's a
     branch for the panel.

 + It's worth mentioning that we should have a message ready about
   deprecated libraries & third parties: distributions will likely need
   those libraries for some more time, and we should make this clear.

 + No specific update about GNOME Shell.

 + Activity journal: the Zeitgeist team didn't propose it yet. Owen sent
   an interesting mail on this topic, which might help make things move.

 + It's important to discuss with the marketing team about expectations.
   GNOME 3.0 will be fully functional, but this is only the beginning of
   the GNOME 3 cycle, and things will continue to evolve. Vincent will
   be at the marketing hackfest in May to help the marketing team.

 + We should try to do regular updates about the 3.0 tasks.

Next meeting

The decisions about new modules will be taken next month, so we will
likely have a meeting at the beginning of May.

Les gens heureux ne sont pas pressés.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]