GNOME plans for the squeeze cycle

[Josselin Mouette]

Le dimanche 16 août 2009 à 14:41 +0200, Marc Brockschmidt a écrit :
> * Which major upstream releases of GNOME are expected in the next two
>   years? Which of those are material for Debian stable, which might be a bit
>   flaky?

GNOME 2.28.0 is due to be released on September 23, with the last stable
release (2.28.2) on December 16.

GNOME 2.30.0, which will probably be 3.0.0 unless new blockers appear,
is due on April 28. Similarly some stable releases are expected for 3-4
months after that.

The GNOME 3.0 release is not expected to break havoc; the most important
change is the list of modules. Since we expect some of the new modules
to be rough around the edges, we intend to ship the 2.x module list, but
to package as many of the new modules as possible.

After that, it is currently not planned to change the fixed release
schedule every ~6 months.

As always, we expect each GNOME release to have its share of brokenness,
especially around new technologies. As always, we may have to back out
some of the upstream changes until they are ready. Here are the things
currently under my radar:
      * DeviceKit: currently it is sitting in experimental; I expect the
        power management stuff to be stabilized by 2.28, but by that
        time new things using DK will be added.
      * PackageKit: this technology is not in an acceptable state for
        Debian, and Ubuntu has started to work on a more suitable
        alternative. In all cases, not something that we can expect to
        be ready for squeeze. If upstream makes it mandatory, it will
        have to be backed out.
      * PulseAudio: it is fully supported right now, but we have patches
        to make it optional since it is still not working on a range of
        hardware. I hope we can continue working this way and simply
        have to take the decision of whether to ship it by default or
        not.
      * GDM: I hope it can be usable at the moment of the 2.28 release.
      * Clutter: it will be made mandatory for some packages, which
        means they won’t work on 3D-accelerated machines. For games this
        is not really a problem, but it is also used by gnome-shell and
        mutter, and I don’t think the drivers will be all stable at the
        3.0 time.
      * Epiphany: the webkit port is doing well but we can expect some
        rough edges for 2.28, especially with the extensions. We may go
        on shipping the gecko version besides for some time if
        necessary.

> * How much time do you usually need from a new upstream release of GNOME
>   to a stable Debian package in unstable?

It depends on several factors.
      * The amount of modules that are not really usable as is; see
        above.
      * The availability of people: if Emilio is accepted by the DAM
        before that time, it will improve things a lot; similarly, if
        Sebastian can be available at that moment, it can vastly reduce
        that time.
      * The reactivity of FTP masters for NEW packages.

If everything goes fine, I think we can do it in one month; if it does
not, that would easily make it three.

Once the .0 version is in squeeze, it is possible to freeze; but I would
recommend, like it was done for lenny, that new stable upstream versions
(which are only for bug fixes and translations) are accepted during the
freeze. 

> * How many "big" transitions will the upcoming changes cause? When should those
>   happen? Can we do something to make them easier?

First, packaging GNOME in one month is feasible, but having it to
migrate to testing in that timeframe is another story. We already did it
successfully in the past, but it requires quite some attention to ensure
that everything builds and migrates smoothly.


A lot of libraries are being deprecated. I have posted a summary[1].
Currently, it looks possible and desirable to remove the following
before the squeeze release:
      * eel: already done
      * gtksourceview 1.x
      * libgnomeprint / libgnomeprintui
      * libsoup 2.2: only one package still using it
      * libnautilus-burn: only the Python bindings are still used
Those which cannot be removed, well, can still be shipped in squeeze,
but be warned that they are not supported upstream anymore. I’d prefer
if we removed them unconditionally.


As for transitions per se, here are the ones already planned:
      * evolution: the move from bonobo to D-Bus (planned for 3.0) will
        certainly not go unnoticed for reverse dependencies, it’s
        possible that even the API changes.
      * at-spi: being completely revamped for 3.0. It has only 2 rdeps
        which don’t belong into GNOME, however.
      * libgda: new version waiting in NEW, API is incompatible.
      * gnome-desktop, libgnomekbd, gucharmap, totem-pl-parser, libepc,
        libgtop2, gtkhtml: you never know when there can be a new soname
        bump in these.
      * gnome-python-desktop and gnome-python-extras: the
        python-gnome2-desktop and python-gnome2-extras binary packages
        will soon be removed, expect a score of uninstallable
        packages[2]. This way, we will be ready to shuffle source
        packages if necessary when upstream decides what happens to all
        deprecated modules.

 [1] http://lists.debian.org/debian-gtk-gnome/2009/04/msg00006.html
 [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=joss@debian.org;tag=gnome-python

Thanks for your interest,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `-     future understand things”  -- Jörg Schilling
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20090816/f59c0f9d/attachment.pgp>