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

Debian GNOME Extras team?



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/

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.

- https://github.com/thecalamityjoe87/paperboy is a Vala app (with a
single embedded Rust library that is not published on
https://crates.io ). It is very new. No idea if it will be proposed
for GNOME Circle. It was recently packaged for Ubuntu.

- balsa. The Debian GNOME team has had an open RFH for this app for 14
years. We have kept the packaging updated but it's not used by active
Debian GNOME contributors. Its code and releases are at
https://gitlab.gnome.org/GNOME/balsa


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

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 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?

Thank you,
Jeremy Bícha


Reply to: