Re: Debian GNOME Extras team?

On 19.12.2025 20:33, Jeremy Bícha wrote:
>I think there is widespread agreement that it makes sense for the
>Debian GNOME team to maintain core GNOME apps and GNOME Circle apps.
>Basically everything listed at https://apps.gnome.org/

Agreed.

>There are other "apps for GNOME" that I think would benefit from team
>maintenance in Debian. Some examples:
>- gthumb is a legacy affiliated app like gimp that is allowed to keep
>using https://gitlab.gnome.org/GNOME/ unlike newer apps which can use
>https://gitlab.gnome.org/GNOME/World/ (or hosted elsewhere). It also
>uses https://download.gnome.org/sources/gthumb/ for its releases. It
>has been orphaned in Debian for years.

Things like BuildStream v2 and Buildbox are certainly things that would
benefit - I would be open to help with that, but I'm not too familiar with
the way Debian 'does' things compared to my maintainership of the two
packages on Nixpkgs.

>Should we create a secondary top-level team for these apps? For
>comparison, there is a Debian KDE Extras Team that appears to have
>about 50 packages compared to the 600+ packages managed by the Debian
>Qt/KDE Maintainers. Here are UDD links since DDPO conflates the 2
>teams because 1 package has its maintainer set incorrectly.
>https://udd.debian.org/dmd.cgi?email1=pkg-kde-extras%40lists.alioth.debian.org
>https://udd.debian.org/dmd.cgi?email1=debian-qt-kde%40lists.debian.org

I think this is reasonable.

>If so, should we go as far as moving all apps there that aren't part
>of either core GNOME or GNOME Circle or are a dependency or
>recommendation of the gnome and gnome-core metapackages? This proposed
>package set would exclude evince, gimp, most games, etc.

I have no opinion on this, other than following upstream as closely as
possible.

>I think some libraries should clearly stay in the existing GNOME team
>when they are used by apps maintained by the team. I think I'd expect
>libraries like libgedit-gfls to go where gedit goes, but there are
>some libraries that are less clear: should gtkmm3.0 stay with gtk+3.0
>and libpeas stay with libpeas2?

I think we should group libraries and associated apps together when we
can, and when its a logical association in the wider context. Those two
examples I would agree with the proposed assertion.

Best regards,
--
Dom Rodriguez (he/him)
Software Engineer

Codethink Ltd

Codethink delivers cutting edge open source design, development and
integration services.

https://codethink.co.uk