at least 25% or more of them would listen to podcasts and that is why I would like GNOME Podcasts added to the repos

Not really sure where you'd get this number.

In terms of it being called "GNOME Podcasts", it's mildly infuriating given the repo is technically "hammond", so I'd like clarification from upstream as to what they intend to call it, and make sure it's consistent.

This got renamed fyi: https://gitlab.gnome.org/World/podcasts

This is going to require Solus to upgrade GTK to 3.24.1 due to dependency on libhandy

I can maybe understand not including it due to the unstable nature of its development, but I am not sure I understand why a libhandy dependency should block Podcasts and Fractal inclusion entirely. By blocking libhandy, hobby developers can't use it easily and GNOME contributors will be unable to easily develop parts of the applications that use it. Is there any way that this decision can be reconsidered at a 1.0.0 release of libhandy? Adding to this, many of the C-based GNOME projects like GCC have Meson options for disabling libhandy support entirely. You seem to be ragging on Podcasts and Fractal for wanting to reach users on various platforms. I agree that projects should probably try to have some form of option to not include the mobile support UI elements, but this seems like more of a personal preference than one that should be enforced on all users of Solus. You can see that I have tried my hand at packaging this (libhandy, Fractal) in the past, so there are people invested in its inclusion. It is just a little baffling to me that web wrappers are good to go in the repository (Discord, etc.), but a desktop application with mobile support at small sizes is not.

Typically, we prefer stable tagged releases. However, this may be waived if:

The software has significant traction (i.e. prerelease)
A bug fix only exists beyond the latest stable release for a git source

This project is gaining traction with GNOME including it in essential applications albeit more geared toward mobile friendly UIs. But here I also concede the unstable API/ABI of the library. It does not seem right to force rebuilds of reverse deps every time this project is updated.

The value added by both Podcasts and Fractal is very high. Podcasts (the media) are extremely popular among people these days. Currently I see 2 desktop podcast clients within the repo: Vocal and GPodder. Never used either of them, but Podcasts get the nod for being endorsed enough by GNOME to be included on their website https://wiki.gnome.org/Apps/Podcasts. To do that, I believe the application has to be fairly conformant to GNOME HIG, which is an obvious value add for people who want a consistent look and feel across their desktop. GPodder for instance sticks out like a sore thumb. On to Fractal. Fractal has the most value add of either of the two. The only Matrix client I can find within the repo is Riot. Riot is an electron application. Electron applications are a poor man's attempt at cross-platform support. Because Riot is an Electron application, support for theming is extremely lacking and it sticks out like a sore thumb. Fractal on the other hand is again referenced by GNOME at https://wiki.gnome.org/Apps/Fractal. It also follows GNOME's HIG (assuming my hypothesis is correct). There is no GTK native alternative that I can find in the repo.

Solus team members reserve the right to permanently reject a package request without the need for further discussion once the rejection is issued. The limited time of contributors should be considered and respected, instead of dragging out and ‘necromancing’ old issues in a vain attempt to force inclusion of previously rejected software. In the event of any policy change, existing/expired package requests will NOT be reevaluated under new criteria as this would lead to an exponential growth in work upon every policy change, and is physically impossible to handle for a project of any size.

I think that this point should be clarified. At the current moment, there are 3 members on the core team and 4 global maintainers. Is it possible to bring contested opinions like this to a vote? Surely not everyone shares the same opinion. If this policy continues to stand, it should be specifically mentioned in the Package Inclusion Policy. Additionally, the scope should be expanded to ban any packages that include Kirigami, but don't allow maintainers to disable the dependency. To my surprise I found that Kirigami is already packaged for Solus at https://dev.getsol.us/source/kirigami2/, so this entire situation requires clarification because if KDE applications which require Kirigami are allowed (ie Plasma's System Settings), then Podcasts and Fractal should be allowed in as well following API/ABI stability of libhandy. I understand one is required for a desktop environment to run, and the others are non-essential.

In summary, please consider this a petition for any application that will make use of libhandy now or in the future to be moved to "Blocked for Inclusion" until libhandy reaches API/ABI stability. This policy purposefully gimps application adoption purely because the developers want their application used on both Mobile and Desktop platforms. For reference libhandy widgets only change when the content no longer fits on the screen. Here are screenshots of both Fractal and Podcasts which obviously show that they are Desktop-oriented applications with the benefit of being usable on a mobile platform in the future (ie Librem 5). It isn't like these applications thrust the user into a mobile UX. The user has to purposefully decrease the window size to see libhandy at work.

Our personal preferences are precisely what makes Solus what it is. We have chosen not to include GNOME Podcasts and ask that you please respect our wishes. Solus is not a democracy. Our pragmatic approach to package inclusion allows us to keep the repo small and our efforts focused. Thank you.

I am aware of all this. I asked for a democracy amongst the powers that be. Not the users like myself. I am not sure how any of what I wrote could be disrespectful. I am merely questioning something which seems like a weird hill to die on, not including a package merely because it depends on libhandy.

Is there any documentation on running a custom Solus repo?