I would keep D-spy at least for now, because that one is a GNOME core app (developer tools).

gnome-extensions-app is part of the gnome-shell package. Recommend not removing gnome-shell.

Agree with the rest.

I took a look at the packages owned by gnome-sig beginning with A, B, and C. I suggest removing:

accerciser, aisleriot, audiofile, bijiben, bitstream-vera-fonts, bluecurve-icon-theme, bogofilter, check, cheese, clutter, clutter-gst3, cogl

That's fully half of the ABC packages. What I would do is remove gnome-sig's ownership of non-core stuff without retiring it, so that other Fedora packagers can continue to maintain the packages if desired. I would only outright retire packages that are clearly obsolete.

Continuing down the list: D, E, and F:

dasher, dbus-glib, dbus-python, dbus-sharp, desktop-backgrounds, devhelp, echo-icon-theme, eog, eog-plugins, epiphany, esound, fedora-screensaver-theme, festival, file-roller, five-or-more, flac, four-in-a-row

That's again nearly half of the packages.

Not sure about the evolution packages. evolution and evolution-ews are not core packages, but evolution-data-server is. But they should surely all get updated together, so I suppose we should keep all three. Either way, we know Milan will update them instead of the gnome-sig-owner.

I'm not brave enough to look over the packages that begin with G right now, but I bet we can remove a whole lot of them.

evolution should probably stay under gnome-sig, as evolution-ews is supposed to become a dependency of gnome-online-accounts in fedora 43 per #461

Okay I removed gnome-sig from bustle for now - I had only added it since the switch to rust was brought to my attention on #workstation.

Would it be helpful to have a SIG or something that groups together all the GNOME-related packages so that it's easier for people to maintain all of them, without any explicit maintenance commitment by the GNOME SIG or the Workstation Working Group.

The SIG could be named something like "GNOME Extras".

Bustle is for instance a GNOME Circle app so even though it's not part of the default Workstation install or core GNOME, it has a close association with GNOME.

We should be able to add evince to the list of droppable packages beginning with E.

I took a look at packages beginning with G. I think we can drop:

GConf2, gconf-editor, geary, gedit, gftp, gitg, glibmm2.4, gmime, gnome-2048, gnome-chess, gnome-common, gnome-console, gnome-dictionary, gnome-doc-utils, gnomes-klotski, gnome-mahjongg, gnome-mime-data, gnome-music, gnome-nettool, gnome-nibbles, gnome-packagekit, gnome-photos, gnome-power-manager, gnome-robots, gnome-sharp, gnome-sudoku, gnome-system-log, gnome-taquin, gnome-terminal, gnome-tetravex, gnome-todo, gnome-usage, gnome-vfs2, gnome-vfs2-monikers, gnote, gthumb, gtk2, gtk2-engines, gtk-sharp2, gtksourceview2, gtksourceview3, gtkspell, gtranslator, gucharmap

We should add: gmime30 (which obsoletes gmime and is not owned by gnome-sig)

Also looking at H, I, J, and K, we can drop: hunspell, hunspell-en, iagno, icon-naming-utils, intltool, krb5-auth-dialog

Looking at L, we can drop: libart_lgpl, libbonobo, libbonoboui, libdazzle, liberation-fonts, libexif, libglade2, libgnome, libgnomecanvas, libgnome-games-support, libgnomekbd, libgnome-keyring, libgpod, libgsf, libgweather, libIDL, libogg, liboil, libpst, libsoup, libtheora, lubutempter, libvorbis, libwnck, libwpe, lightsoff

I'm looking for packages that are (a) obsolete (these should be retired rather than merely orphaned), (b) not core to GNOME desktop (e.g. gedit) or not core to Fedora Workstation (epiphany, gnome-music, gnome-console), (c) in a few cases, packages that are essential but not clearly connected to GNOME (hunspell, liberation-fonts, libexif)

I decided not to include libgdata on this list, even though it is obsolete and insecure, because that would take out our Google account integration. We can deal with our reckoning on that separately. I also kept a gtk-doc and libhandy even though they are obsolete.

Looking at M, we can drop: media-player-info, metacity, mingw-adwaita-icon-theme, mingw-colord, mingw-hicolor-icon-theme, mingw-libcroco, mingw-libgusb, mingw-librsvg2, mousetweaks

Looking at N and O, we can drop: ORBit2

Not sure about: nautilus-python

Looking at P, Q, R, we can drop: PackageKit, PackageKit-Qt, polari, pygobject2, pygtk2, qqwing, quadrapassel, redhat-menus,

I also want to drop rhythmbox, but see #33.

Looking at S, we can drop: seahorse, seahorse-nautilus, shotwell, sound-juicer, speex, speexdsp, swell-foop

Looking at T, we can drop: tali, totem, tracker, tracker-miners

Looking at U and V, we can drop: vinagre, vorbis-tools, vte

Looking at W, X, Y, Z we can drop: wpebackend-fdo, ytnef, zenity

This list is maximalist: I've proposed removing non-obsolete applications that are just not core to the desktop, on the assumption that other packagers will choose to maintain them if desired. A few of the packages are even things I would maintain myself (e.g. epiphany). @jbicha suggests a second GNOME SIG to help with maintaining this stuff. I'm not sure whether or not having two SIGs is really a good idea.

gnome-extensions-app is part of the gnome-shell package.

It looks like this should be retired. It used to be a separate package, but it got merged into gnome-shell.

I have replaced the meeting tag with meeting-request, because Felipe is currently away, and we'll want him for this discussion. Then when Felipe returns, I will be away. Let's schedule this for after GUADEC.

I think you need to keep libgweather

You're right. I assumed that was obsolete, but actually it's libgweather4 that is obsolete, so we can drop that one instead.

Actually libgweather4 is already retired. We can safely drop ownership of retired packages.

Tomas suggests we should start with a phased approach: instead of dropping ownership of all non-core packages like I suggest, we should start with dropping only clearly obsolete stuff. E.g. we would keep non-core but non-obsolete stuff like Evince or Totem. This would be a much smaller set of packages than I suggested. (But we could consider dropping more in the future, if desired.)

That seems a reasonable approach to me

I chatted with Felipe about this and we both agree with Tomas's suggested approach. Action: Michael and Felipe to prepare a new proposal, dropping only clearly obsolete packages or packages that are not closely related to GNOME.

I'll remove the meeting-request tag because we don't need to discuss this at the meeting until after we have a new proposal.

We put together a proposal of obsolete packages we intent to orphan. Some of these packages have dependencies to review. Some are already retired, but are still owned by gnome-sig group.

• GConf2
• clutter
• clutter-gst3
• cogl
• dbus-glib
• dbus-sharp
• fedora-screensaver-theme
• gconf-editor
• glycin-loaders
• gmime
• gnome-common
• gnome-dictionary
• gnome-doc-utils
• gnome-icon-theme
• gnome-mime-data
• gnome-nettool (consider archiving upstream)
• gnome-packagekit (consider archiving upstream)
• gnome-photos
• gnome-screenshot (gnome-shell has now builtin screenshots)
• gnome-sharp (https://github.com/mono/gnome-sharp)
• gnome-system-log
• gnome-themes-extra
• gnome-vfs2
• gnome-vfs2-monikers
• gtk2
• gtk2-engines
• gtk-sharp2
• gtksourceview2
• gtksourceview3
• gtkspell
• icon-naming-utils
• libart_lgpl
• libbonobo
• libbonoboui
• libdazzle
• libglade2
• libgnome
• libgnomecanvas
• libgnome-games-support (need to update deps first)
• libgnomekbd
• libgnome-keyring
• libgweather4
• libsoup
• libIDL
• liboil
• libwpe
• mousetweaks
• ORBit2
• pygobject2
• pygtk2
• tracker
• tracker-miners
• vinagre
• vte
• wpebackend-fdo

Update by mcatanzaro: added gmime, glycin-loaders, gnome-doc-utils, and seahorse-nautilus to list

Also, a list of non-obsolete packages that we should drop because they do not need to be maintained by gnome-sig:

• NetworkManager
• audiofile
• bitstream-vera-fonts
• bluecurve-icon-theme
• bogofilter
• check
• dasher
• desktop-backgrounds
• echo-icon-theme
• esound
• festival
• flac
• fontconfig
• freetype
• fribidi
• gftp
• highlight
• hunspell
• hunspell-en
• intltool
• iso-codes
• lcms
• liberation-fonts
• libexif
• libgpod
• libogg
• libpst
• libtheora
• libutempter
• media-player-info
• mingw-adwaita-icon-theme
• mingw-colord
• mingw-hicolor-icon-theme
• mingw-libcroco
• mingw-libgusb
• mingw-librsvg2
• PackageKit-Qt
• pycairo
• qqwing
• rdesktop
• speex
• speexdsp
• vorbis-tools
• ytnef

(I couldn't decide whether to add NetworkManager or not.)

Updates: Added NetworkManager to this list. Removed krb5-auth-dialog.

Packages that are not or no longer core or strategic to Fedora Workstation, which I had previously planned to drop, but which we can continue maintaining for now:

• accerciser
• aisleriot
• bijiben (renamed upstream to gnome-notes, needs renamed downstream)
• cheese
• devhelp
• eog
• eog-plugins
• epiphany
• evince
• evolution
• file-roller
• five-or-more
• four-in-a-row
• geary
• gedit
• gitg
• gnome-2048
• gnome-chess
• gnome-console
• gnome-klotski
• gnome-mines
• gnome-nibbles
• gnome-power-manager
• gnome-remote-desktop
• gnome-sound-recorder (renamed upstream to Vocalis, but no release yet)
• gnome-sudoku
• gnome-taquin
• gnome-terminal
• gnome-tetravex
• gnome-todo
• gnome-usage
• gnote
• gthumb
• gtranslator
• gucharmap
• iagno
• libgsf
• libhandy
• libwnck
• lightsoff
• metacity
• polari
• pyatspi (needs renamed to pyatspi2)
• quadrapassel
• rhythmbox
• seahorse
• seahorse-nautilus
• shotwell
• sound-juicer
• swell-foop
• tali
• totem
• zenity

I forgot to mention during our meeting today, but we have one more list: packages where gnome-sig has commit-only and needs admin access. We have very recently started to consider admin access to determine whether gnome-sig is responsible for updating the package, which means we need to add admin permissions to a lot of packages that don't have it currently.

Many of these packages are also on the non-core/non-strategic list.

• colord-gtk
• dbus? (sort of obsolete, but gdm still depends on it)
• eog-plugins
• geary
• gi-docgen (talk to packager first)
• gitg
• gnome-2048
• gnome-app-list
• gnome-builder
• gnome-characters
• gnome-chess
• gnome-control-center
• gnome-disk-utility
• gnome-extensions-app (confirm with fmueller)
• gnome-klotski
• gnome-logs
• gnome-mines
• gnome-nibbles
• gnome-power-manager
• gnome-remote-desktop
• gnome-sound-recorder
• gnome-sudoku
• gnome-system-monitor
• gnome-taquin
• gnome-tetravex
• gnome-todo
• gom
• grilo
• grilo-plugins
• gsound
• gthumb
• gtranslator
• gucharmap
• libdex
• libgit2-glib
• libgsf
• libgtop2
• libmediaart
• libspelling
• libwnck
• lightsoff
• localsearch
• metacity
• nautilus-python
• pango
• polari
• ptyxis
• quadrapassel
• rhythmbox
• simple-scan
• sound-juicer
• swell-foop
• tali
• tinysparql

Update: added simple-scan. Removed obsolete seahorse-nautilus and gnome-doc-utils. Remove Rust stuff: bustle, glycin, gnome-robots, gnome-user-share

Please complain if you see something that looks wrong. We'll wait until next week before we implement any changes.

• Packages from the first list: we'll drop gnome-sig commit/admin access and also contact the package owner to suggest orphaning the package (if it's not already retired).
• Packages from the second list: we will drop gnome-sig commit/admin access.
• Packages from the third list: no changes.
• Packages from the fourth list: we will add gnome-sig admin access.

One more clarification: orphaned packages may be claimed by any other Fedora packager; e.g. it's unlikely that gtk2 will be retired from Fedora even though we intend to orphan it. Any packager can claim an orphaned package.

A subset of the first list, packages that are already retired or likely to be retired soon:

• fedora-screensaver-theme
• gnome-themes-extra (recently orphaned, likely to be retired imminently)
• libgweather4
• libwpe
• pygobject2
• pygtk2
• tracker
• tracker-miners
• wpebackend-fdo

@tpopela we can drop commit access to these now, without waiting until next week, since there's no point in maintaining access to packages that are retired.

I've opened https://pagure.io/releng/issue/12914 after talking to jednorozec.

Packages that are not or no longer core or strategic to Fedora Workstation, which I had previously planned to drop, but which we can continue maintaining for now:
[…]

Thank you for keeping these! At least some of them are still important and useful and too core to be installed from flatpak.

I forgot to mention during our meeting today, but we have one more list: packages where gnome-sig has commit-only and needs admin access. We have very recently started to consider admin access to determine whether gnome-sig is responsible for updating the package, which means we need to add admin permissions to a lot of packages that don't have it currently.

Many of these packages are also on the non-core/non-strategic list.
[…]
- dbus? (sort of obsolete, but gdm still depends on it)
[…]

quite a lot of packages are depending on dbus, such as bluez, cups, dnf5daemon-server, fctix, gnome-control-center, gnome-terminal, gnome-maps, gnome-session, loupe, systemd, and a few more

I'm adding gmime to the obsolete list.

quite a lot of packages are depending on dbus, such as bluez, cups, dnf5daemon-server, fctix, gnome-control-center, gnome-terminal, gnome-maps, gnome-session, loupe, systemd, and a few more

Right, we need to eventually fix that.

Packages that need to be renamed to match upstream:

• bijiben -> gnome-notes
• gnome-todo -> endeavour
• pyatspi -> pyatspi2
• Future: gnome-sound-recorder -> vocalis

gnome-notes never had a release with that name :(

I don't think there is a benefit to renaming pyatspi to pyatspi2. Generally we prefer unversioned names. Repology. (Solus is the only distro I see using the pyatspi2 name).

gnome-notes never had a release with that name :(

Ah, OK then. We should surely only rename after a release exists.

I don't think there is a benefit to renaming pyatspi to pyatspi2. Generally we prefer unversioned names. Repology. (Solus is the only distro I see using the pyatspi2 name).

Unversioned names are better, yes, but in this case the actual upstream project is literally named "pyatspi2" and matching upstream is probably the most important consideration, right? Well, it's not too important; we can just ignore it.

Packages that we update but which gnome-sig has no access to:

• brasero, arguably obsolete but still in ELN
• gedit-plugins
• ghex
• gmime30
• gnome-multi-writer, but this seems clearly obsolete so let's not add it
• gnome-video-effects, required by cheese
• gupnp-dlna
• gupnp-tools
• libgda
• libgee
• libgepub
• libsigc++30
• totem-pl-parser

Many of these packages are also on the non-core/non-strategic list.
...
- localsearch
- tinysparql

LocalSearch and TinySPARQL absolutely are core, they're what used to be called Tracker-Miners and Tracker, respectively, which power the entire GNOME Shell search feature.

https://gitlab.gnome.org/GNOME/tinysparql
https://gitlab.gnome.org/GNOME/localsearch

That's the list of packages where we do not have admin permission, but should, because we are now only updating packages where we have admin permission.

@tpopela Can you help implement this please?

• Drop gnome-sig permissions from these packages and these packages. Don't drop libgnome-games-support quite yet.
• Add gnome-sig admin permissions to these packages and these packages. Don't add gnome-multi-writer.
• Update: Replace admin permissions with commit permissions on Rust packages: librsvg2, loupe, snapshot, rust-glycin, rust-glycin-utils

I'd also like to contact the maintainers of the first list of packages to suggest orphaning them. However, that requires a small amount of time and effort. Help welcome.

@tpopela Can you help implement this please?

• Drop gnome-sig permissions from these packages and these packages. Don't drop libgnome-games-support quite yet.

Requested in https://pagure.io/releng/issue/12930

• Add gnome-sig admin permissions to these packages and these packages. Don't add gnome-multi-writer.
• Update: Replace admin permissions with commit permissions on Rust packages: librsvg2, loupe, snapshot, rust-glycin, rust-glycin-utils

I think that for this we would have to get the approval from the main admins before doing so. I personally wouldn't be happy if someone from releng would add gnome-sig as an admin to my package without being notified before. I will work on the list of people that needs to be contacted (without the people that are already in gnome-sig)

list of packages and contacts from https://pagure.io/fedora-workstation/issue/483#comment-983358 :

list of packages and contacts from https://pagure.io/fedora-workstation/issue/483#comment-983549 :

I forgot to mention during our meeting today, but we have one more list: packages where gnome-sig has commit-only and needs admin access.

• gi-docgen (talk to packager first)

I have upgraded gnome-sig’s permissions on gi-docgen to admin.

• Drop gnome-sig permissions from these packages and these packages. Don't drop libgnome-games-support quite yet.

Requested in https://pagure.io/releng/issue/12930

This is resolved now.

@aekoroglu, @alexpl, @amigadave, @atim, @carlwgeorge, @catanzaro, @chkr, @dodji, @feborges,
@fmuellner, @hobbes1069, @ignatenkobrain, @jadahl, @jonathanspw, @jwrdegoede, @kalev, @laxathom, @lennart, @limb, @lkundrak, @ngompa, @nmontero, @nphilipp, @otaylor, @pwu, @rathann, @raveit65, @rhughes, @robert, @salimma, @slaanesh, @tagoh, @tdawson, @thm, @ueno, @victortoso, @walters, @yaneti, @yselkowitz

if you would like the gnome-sig to maintain the packages which you're admins of (see the list in https://pagure.io/fedora-workstation/issue/483#comment-984359), please add the gnome-sig group as an admin or let us know here and we will ask the releng to do it.

gnome-extensions-app is part of the gnome-shell package.

It looks like this should be retired. It used to be a separate package, but it got merged into gnome-shell.

Not quite. The code has always been part of gnome-shell, but it was decided early on to move it into a separate package (I think because of Fedora flatpaks, but may be wrong).

I am considering splitting the code into a different upstream repo for GNOME 50 btw (mainly so contributors can use the regular flatpak workflow). Some of the untangling of common deps was already done in 49, but it's not a priority and so the split itself got deferred.

I gave gnome-sig admin permissions on gnome-extensions-app now, although from my POV the flathub version is the preferred option.

@aekoroglu, @alexpl, @amigadave, @atim, @carlwgeorge, @catanzaro, @chkr, @dodji, @feborges,
@fmuellner, @hobbes1069, @ignatenkobrain, @jadahl, @jonathanspw, @jwrdegoede, @kalev, @laxathom, @lennart, @limb, @lkundrak, @ngompa, @nmontero, @nphilipp, @otaylor, @pwu, @rathann, @raveit65, @rhughes, @robert, @salimma, @slaanesh, @tagoh, @tdawson, @thm, @ueno, @victortoso, @walters, @yaneti, @yselkowitz

if you would like the gnome-sig to maintain the packages which you're admins of (see the list in https://pagure.io/fedora-workstation/issue/483#comment-984359), please add the gnome-sig group as an admin or let us know here and we will ask the releng to do it.

Done for gucharmap.

Could you actually undo this change for gucharmap please? I should not have added it to this list because it hasn't had a new tarball release in a very long time. I see it's still releasing git tags, but those require manual handling. gucharmap is largely obsoleted by gnome-characters, and it's only worth maintaining if it's easy.

(I was investigating gucharmap just now by coincidence after noticing the discrepancy between release tags and tarballs.)

(We're using admin vs. commit permission to indicate primary update responsibility.)

@carlwgeorge for libspelling, please either keep gnome-sig as commit-only access (ignore the request to add admin permission, we will stop updating it, you handle the updates) or disable "This project does not support direct push to its git repo, all changes must be done via pull-requests from forks," whichever you prefer.

Could you actually undo this change for gucharmap please? I should not have added it to this list because it hasn't had a new tarball release in a very long time. I see it's still releasing git tags, but those require manual handling. gucharmap is largely obsoleted by gnome-characters, and it's only worth maintaining if it's easy.

(I was investigating gucharmap just now by coincidence after noticing the discrepancy between release tags and tarballs.)

(We're using admin vs. commit permission to indicate primary update responsibility.)

gucharmap is back to commit permission.

@aekoroglu, @alexpl, @amigadave, @atim, @carlwgeorge, @catanzaro, @chkr, @dodji, @feborges,
@fmuellner, @hobbes1069, @ignatenkobrain, @jadahl, @jonathanspw, @jwrdegoede, @kalev, @laxathom, @lennart, @limb, @lkundrak, @ngompa, @nmontero, @nphilipp, @otaylor, @pwu, @rathann, @raveit65, @rhughes, @robert, @salimma, @slaanesh, @tagoh, @tdawson, @thm, @ueno, @victortoso, @walters, @yaneti, @yselkowitz

if you would like the gnome-sig to maintain the packages which you're admins of (see the list in https://pagure.io/fedora-workstation/issue/483#comment-984359), please add the gnome-sig group as an admin or let us know here and we will ask the releng to do it.

Upgraded @gnome-sig to admin on gitg. I use gitg, so I will keep maintaining it for now. Happy to coordinate updates or builds in your side-tags.

I have given the gnome-sig group admin rights on sound-juicer.

@aekoroglu, @alexpl, @amigadave, @atim, @carlwgeorge, @catanzaro, @chkr, @dodji, @feborges,
@fmuellner, @hobbes1069, @ignatenkobrain, @jadahl, @jonathanspw, @jwrdegoede, @kalev, @laxathom, @lennart, @limb, @lkundrak, @ngompa, @nmontero, @nphilipp, @otaylor, @pwu, @rathann, @raveit65, @rhughes, @robert, @salimma, @slaanesh, @tagoh, @tdawson, @thm, @ueno, @victortoso, @walters, @yaneti, @yselkowitz

if you would like the gnome-sig to maintain the packages which you're admins of (see the list in https://pagure.io/fedora-workstation/issue/483#comment-984359), please add the gnome-sig group as an admin or let us know here and we will ask the releng to do it.

Updated @gnome-sig to admin on pango.

I think @tagoh has updated the admin access for pango.

Does anyone know why gnome-sig isn't on libpeas1?

libpeas1 is obsolete. We are intentionally dropping ownership of anything that is obsolete. A bunch of older GNOME applications still use it unfortunately, but no modern GNOME applications do.

(That said, gnome-sig never had permission to commit to libpeas1.)

From https://pagure.io/fedora-workstation/issue/483#comment-984359 we're down to:

brasero
dbus
eog-plugins
geary
gedit-plugins
ghex
gmime30
gnome-2048
gnome-app-list
gnome-builder
gnome-chess
gnome-control-center
gnome-disk-utility
gnome-klotski
gnome-logs
gnome-mines
gnome-power-manager
gnome-sound-recorder
gnome-sudoku
gnome-system-monitor
gnome-taquin
gnome-tetravex
gnome-todo
gnome-video-effects
gom
grilo
grilo-plugins
gsound
gthumb
gupnp-dlna
gupnp-tools
libdex
libgee
libgepub
libgit2-glib
libgtop2
libmediaart
libsigc++30
libspelling
libwnck
lightsoff
localsearch
nautilus-python
ptyxis
quadrapassel
rhythmbox
simple-scan
swell-foop
tali
tinysparql
totem-pl-parser

And I've send an email to the package admins.

We have very recently started to consider admin access to determine whether gnome-sig is responsible for updating the package, which means we need to add admin permissions to a lot of packages that don't have it currently.

Why require admin for that?

@carlwgeorge for libspelling, please either keep gnome-sig as commit-only access (ignore the request to add admin permission, we will stop updating it, you handle the updates) or disable "This project does not support direct push to its git repo, all changes must be done via pull-requests from forks," whichever you prefer.

I prefer to keep that package how it is currently configured, with gnome-sig commit permission and all changes going through pull requests. This request comes across as "give us full blown admin permissions or let us make changes without review, otherwise we won't help maintain the package". I'm happy to have gnome-sig assistance with the package (hence granting gnome-sig commit permissions in the first place), but I do not view these conditions as reasonable.

Why require admin for that?

There's no valid technical reason for it. Commit permission is sufficient to do everything we need to do.

We're just using the admin permission as an indication that gnome-sig has primary update responsibility rather than the package owner.

This request comes across as "give us full blown admin permissions or let us make changes without review, otherwise we won't help maintain the package".

That is exactly what this is. :)

We have hundreds of packages to maintain, so it's not reasonable to expect us to create pull requests. I already removed libspelling from release automation because the pull request setting blocked mclazy from pushing to the repo. I see Nieves was manually creating pull requests for you, but there's no way I'm going to take the time to do that.

It's perfectly fine to leave libspelling as commit-only access and require pull requests, so long as you're OK with updating it yourself. No action required on your part if this is what you want. We just won't update it for you, that's all. I recommend configuring Packit to create pull requests for you if you do this, so you don't have to remember to do it yourself.

With this patch for Swell Foop, nothing should depend on libgnome-games-support anymore. We'll be able to obsolete this package. (libgnome-games-support1 is still required, but already not maintained by gnome-sig.)

gedit now comprises several packages:

libgedit-amtk
libgedit-gtksourceview
libgedit-tepl
gedit
gedit-plugins

I'm of course aware that gedit is no longer the default GNOME text editor. Does gnome-sig want to help maintain all of these? If so (and I don't mind if you do), I'll add the missing perms, but otherwise I'll drop you from gedit.

The difference is the libgedit packages do not have tarball releases on download.gnome.org, whereas gedit and gedit-plugins both do (for now, at least). So I'd say we don't want admin permissions for the libgedit packages; those aren't packages we would update automatically or indeed ever look at unless the gedit build fails because a newer version is needed. We could accept commit permissions, though, which would allow us to manually build a newer version on occasion if needed to update gedit itself.

It's also perfectly fine to remove gnome-sig if you prefer, or simply change it from admin permission to commit permission, if you prefer to manage routine updates yourself.

The latest versions of gedit and gedit-plugins are only available from Gitlab tags, not from the GNOME tarball download site.

Probably best to just remove them, then.

My packages should be set now.

I've removed gedit and gedit-plugins from our spreadsheet.

@tpopela We need admin help to drop commit access from krb5-auth-dialog, which has been orphaned.

@tpopela We need admin help to drop commit access from krb5-auth-dialog, which has been orphaned.

https://pagure.io/releng/issue/13017

We still don't have the gnome-sig added for the following packages (I've sent two emails to the maintainers):

brasero hobbes1069,laxathom
dbus amigadave,lennart,walters
eog-plugins kalev
ghex dodji,kalev
gmime30 kalev
gnome-builder amigadave,ignatenkobrain
gnome-chess kalev
gnome-disk-utility amigadave
gnome-klotski kalev
gnome-logs amigadave
gnome-sound-recorder amigadave
gnome-system-monitor kalev
gnome-tetravex kalev
gnome-todo amigadave,kalev
gom kalev
gthumb chkr
gupnp-dlna kalev
gupnp-tools kalev
libdex amigadave
libgepub kalev
libgtop2 kalev
libsigc++30 kalev
libwnck jonathanspw
lightsoff kalev
quadrapassel kalev
rhythmbox amigadave
simple-scan amigadave,dodji,ignatenkobrain,slaanesh
tali kalev
totem-pl-parser kalev

We're down to:

brasero hobbes1069,laxathom
dbus amigadave,lennart,walters
ghex dodji,kalev
gnome-builder amigadave,ignatenkobrain
gnome-disk-utility amigadave
gnome-logs amigadave
gnome-sound-recorder amigadave
gthumb chkr
libdex amigadave
libwnck jonathanspw
rhythmbox amigadave
simple-scan amigadave,dodji,ignatenkobrain,slaanesh

At this point, I suggest it's time to start the non-responsive maintainer process for the remaining maintainers, as it's been several months now and it's safe to say attempts to contact the maintainers have failed. Many of these maintainers stopped contributing to Fedora packaging long ago.

Although I see Kalev did respond and grant access to most of his packages. Looks like he just missed ghex?

Although I see Kalev did respond and grant access to most of his packages. Looks like he just missed ghex?

ghex's main admin is @dodji , so Kale shouldn't transfer the ownership to Matthias

Somewhat off-topic, but is there any reason why the gamemode package is preinstalled on Workstation?

https://pagure.io/fedora-workstation/issue/88

https://pagure.io/fedora-workstation/issue/88

I see. Been wondering since gamemode doesn't appear to be popular these days, not to mention that at least some of its devs seem to have no idea what they're doing.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/workstation/tickets/issues/483

Please continue any further discussion there.