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
