Transition maintenance of GNOME to GNOME Team

In order to successfully implement tsc#46 (closed) for the GNOME Team, we need to figure out what are the responsibilities that apply specifically to us. What is the team supposed to take maintenance over, and what should still be under responsibility of individuals. This is specially important since GNOME has a lot of projects under its umbrella, with different goals and ideas. I believe that dumping everything directly into the team could promote the "bystander syndrome" that we want to avoid. For this reason, I have been looking into the multiple packages related to GNOME that exist in aports over the last couple of days and wanted to open a discussion about this. I have tried to gather all the packages that exist in aports related to this, but this is certainly not exhaustive, so let me know if you find missing packages worth mentioning.

In the following, it is a structured list of opinionated groups of GNOME packages and how I believe we should proceed with them. Ideas for improvements to this categorization are welcomed.

GNOME Core Apps

Taken list from upstream: https://apps.gnome.org/ These are the apps that upstream consider crucial part of their ecosystem. I like following upstream judgement, so I would propose that the team take maintenance for all these apps. It is also worth mentioning that there are 3 apps which we don't package: gnome-text-editor, gnome-connections and gnome-logs. The later might only be relevant with systemd, but the other 2 we should probably consider packaging.

• baobab
• calls
• cheese
• eog
• evince
• epiphany
• gnome-calculator
• gnome-calendar
• gnome-characters
• gnome-clocks
• gnome-connections
• gnome-console
• gnome-contacts
• gnome-control-center
• gnome-disk-utility
• gnome-font-viewer
• gnome-maps
• gnome-music
• gnome-photos
• gnome-shell-extensions
• gnome-software !43838 (merged)
• gnome-system-monitor
• gnome-tour
• gnome-weather
• nautilus
• seahorse
• simple-scan
• totem
• yelp

GNOME desktop "system" packages

This is an opinionated group of packages that conform the core of system programs which run what people would call the "GNOME Desktop", starting by the gnome-shell. My understanding is that these are also components which are exclusively used under GNOME. In my opinion, we should also take maintenance over these ones:

• adwaita-icon-theme
• gdm
• gnome-backgrounds
• gnome-bluetooth
• gnome-desktop
• gnome-initial-setup
• gnome-keyring
• gnome-remote-desktop
• gnome-session
• gnome-shell
• gnome-user-docs
• gsettings-desktop-schemas
• gvfs
• mutter
• orca
• xdg-desktop-portal-gnome
• yelp-xsl
• yelp-tools

Other GNOME apps

This is an as-exhaustive-as-I-could list of other apps that we package. Some of them follow the org.gnome. for their id prefix, some don't. Some are part of GNOME Circle (for overview of what it is, see this post), and some part of the main GNOME group in gitlab. There are also some which are listed in https://apps.gnome.org/ as "Development Apps". In general, I believe the team should not take maintenance over these and individuals should be maintainers instead. My rationale is that in the majority of the cases they are not important enough to GNOME for everybody to care enough and the bystander syndrome could easily become real. I have sub-categorized these in two groups, based on whether they do or do not follow upstream release schedule (which makes them even harder to maintain as a team):

Apps that follow the release cycle

I'd be open to take maintenance over some of these as a team if other people care enough:

• devhelp
• gedit
• gedit-plugins
• ghex
• gnome-boxes
• gnome-builder
• gnome-chess
• gnome-firmware-updater -> We should rename it to gnome-firmware to align with upstream naming
• gnome-sudoku
• gnome-sound-recorder
• gnome-tweaks
• highscore

Apps that do not follow the release cycle

I would avoid maintaining these as a team. Specifically, I believe things under GNOME Circle shall be taken care by individuals. Probably there are many more apps in this category than here mentioned. Which I believe is a good thing :D

• aisleriot
• dconf-editor
• network-manager-applet
• geary
• gnome-2048
• gnome-authenticator -> Rename to authenticator, since it's part of Circle.
• gnome-feeds -> Rename to gfeeds to align with upstream.
• gnome-mines
• obfuscate -> Rename to obfuscate, since it's part of Circle, not of core GNOME Renamed: !37028 (merged)
• gnome-passwordsafe -> Rename to secrets, since it was renamed and part of Circle
• gnome-podcasts -> Rename to podcasts, since part of Circle
• gnome-power-manager
• gnome-shortwave -> Rename to shortwave, since part of Circle
• gnome-taquin
• gnome-terminal -> People are used to it and while it's maintained, probably makes sense to keep it in gnome metapackage and team maintenance.
• gnome-usage
• grilo
• grilo-plugins
• sysprof
• vinagre

Packages part of the "GNOME classic desktop"

These seem to be badly maintained upstream and I don't see the point of having these under the team effort. I personally don't even see the point of having these packaged since they add to the maintenance overhead (gnome-bluetooth-3 had to be added just for this reason) and provide few features (are there any users of them?). I would hope anybody wanting the classic experience is on Mate or XFCE. But surely I have nothing to back up my feelings, so I'm ok with just not having them under team maintenance.

• gnome-applets
• gnome-flashback
• gnome-menus -> Haven't seen a release since March 2020!
• gnome-panel

Libraries and glue packages related to GNOME

This is were certainly there are most packages missing. I don't have a strong opinion about these ones, and I'll follow whatever other people consider best. Some could also have been included in the "system" packages above, I am just not super sure how much some of these are used outside gnome:

• chrome-gnome-shell -> Works in all browsers. Could be maybe renamed?
• dconf
• gcr
• gjs
• glib Usage is much broader than just GNOME
• glib-networking
• gnome-autoar
• gnome-online-accounts
• gst-* -> Just here for completion
• gtk -> There is gtk+2.0, gtk+3.0, gtk4.0. Usage is much broader than just GNOME
• gtkmm -> There is gtkmm3, 4
• gtksourceview -> There is gtksourceview, 2, 4, 5, mm3, mm4!!
• gtk-vnc
• libadwaita
• libdazzle
• libgnome-games-support
• libgudev
• libgusb
• libgweather4
• libhandy1
• libnma
• libsecret
• libsoup -> This is used in many more places, just here for completion
• mozjs -> This is not GNOME, but gjs seems to be the main consumer
• networkmanager* -> Just here for completion
• pango -> Usage is much broader than just GNOME.
• rest -> Should probably be renamed to librest
• tracker
• tracker-miners
• vte

Deprecated or things I couldn't categorize

• gnome-books -> Unmaintained upstream 596afb61
• gnome-screenshot -> Now the shell carries this! It is now deprecated.
• gnome-themes-extra -> See https://gitlab.gnome.org/Teams/Design/initiatives/-/issues/107. Should be ready to remove for GNOME 43 !40582 (merged)
• gnome-common -> Old m4 macros. Should remove. Moved to testing instead !43666 (merged)
• gnome-doc-utils -> It's archived upstream! !43675 (merged)
• gnome-colors -> This is not part of upstream regardless of its name (which might even be a TM violation?). Last release in 2015. I would be happy to drop it.
• gnome-games -> It's archived upstream! Replaced by highscore, which is only in testing
• gnome-getting-started-docs -> It's archived upstream! I guess it was replaced by gnome-user-docs
• gnome-latex -> It's archived upstream!
• gnome-online-miners -> Mentioned by tracker-miners. Not sure if still needed.
• gpaste -> This is not part of GNOME although it follows the official versioning
• libgnome-keyring -> It's archived upstream!
• libgnomekbd -> Last release February 2019!
• libgtop -> Hasn't seen a release in 3 years and a commit in 1 year, but still seems like lots of things depend on it?

If you've read this far, you've probably realized how opinionated this is 😄 Looking forward to listen to other people's thoughts.

@team/gnome