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
Reply to: