-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GNOME module list suggestions #3
Comments
Thanks for the detailed feedback! I was indeed trying to cast a wide net. Regarding missing modules, I like your suggestion for a split -- if I'm understanding correctly, we'd end up with three categories: "F/OSS desktop plumbing", "GNOME platform/infrastructure/docs" and "GNOME/GTK flagship applications". Then we could get a better fix on how the platform proper is doing, and expand the plumbing and applications lists a bit. I guess minimum criteria for the latter could be "more than $N LOC, relies on GTK widgets". Or maybe instead of/in addition to LOC we could select by number of downloads on Flathub, or distro numbers (Debian popcon?). As a footnote, I guess the questions I'd like to answer are along the lines of:
I was interested in the C# projects because they were developed by people with vast GNOME experience and intended as desktop centerpieces, but the technology occupied an awkward space and was eventually rejected. There have been other projects that met with dead ends too, and I thought it made sense to include them because I see it as part of the group effort. Similar things happen within modules when branches fail to be merged or code is rewritten/retired. |
If I may chip into the bikeshed... Maybe aggregating all the jhbuild modulesets over time would be interesting. I saw that gnome-panel is missing, which was a big part of the action in GNOME2. I like the idea of splitting by categories! I suppose you'll find much more drive-by contribution in applications than in the core platform, but who knows. |
I was imagining two categories: "GNOME" and "core dependencies". The primary motivation for that is to remove any skew from projects that are (semi)independent from GNOME and whose "health" might not reflect the health of the GNOME project itself. For example, I don't think contributions to GStreamer, which is used far more widely than GNOME and is fairly independent, can be simply interpreted as commits to the GNOME project. This isn't to say that these core dependencies aren't important to GNOME, or that contributions to them aren't relevant to us, which is why I'd analyse them separately. To me, creating categories for platform/infrastructure/docs versus GNOME/GTK is potentially interesting, but has a different goal. My suggestion is intended to ensure validity of the analysis. (Side note: if we were to examine levels of contribution across modules - super interesting! - I would personally be more interested in identifying categories empirically rather than a priori. Which modules are most active over time? Which ones have low/high contributor turnover? etc, etc.) (Edit: also on per module contribution levels - it would be really interesting to analyse which modules are primarily supported by which companies. You might well see that some are primarily developed by one company, whereas others have shared support.) |
Fair enough. GStreamer felt GNOME-y to me because of its strong GLib tradition and usefulness to the desktop, and the developers sometimes show up at GUADEC too. I'm toying with the idea of a "plumbing" category that could serve the function of "core dependencies" for more DEs than just GNOME. May be a pipe dream though. It depends on what other projects would consider core and not (e.g. KDE vs. Qt). |
if I may also chime into the bikeshed. I find the question about important underlying libraries very interesting. With my gstreamer hat on I could tell you that intersection between a gst and a gnome developer is a sizable group of people, but there are also a lot of activity that comes from other sources. The way that activity would be counted, if at all, would be very interesting, do we identify the people with strong associations to gnome and group the rest separately? Should those projects get a plumbing category of their own? Do we ignore them for now to avoid the hassle? I think those are similar to other sizable projects, like mesa, systemd, pulse, webkit, NetworkManager, wayland family, xorg too, or probably most of the projects hosted on freedesktop.org infrastructure. We will likely find former or still active gnome people involved with the majority of them and being heavily invested into them. There's also another category of fd.o projects that exist currently where they are developed mostly by gnome people, but given their nature that will likely change in the future are they are meant as generic infrastructure. What comes to mind is things like bolt, upower, accountservice, pkg-config, libfprint, plymouth, and probably more of them. I don't really know how to conclude this comment other than, dumping theses shower thoughts here. But I really appreciate the effort that has been put into these analytics/metric and its very valuable! Thank you! |
Which modules are included in the definition of GNOME is one of the trickiest aspects of measuring activity in the project, and is something I've struggled with myself in the past. That said, looking at the list of modules, I'd suggest a few changes:
Core dependencies
The list includes a number of core dependencies which, while they are vital and important to GNOME, have a significant life beyond the project. This includes:
The concern here is that a project like gstreamer or wayland could skew the results.
My suggestion would be to remove these modules from the analysis, and possibly conduct a separate analysis for this set of modules.
There are a bunch of libraries which have a similar status, including:
It might be good to include those in the "core dependencies" group.
Edit: actually, there's a huge list of additional core dependencies we could consider. Certainly
udisks2
andupower
should be in there. I also wonder aboutbuildstream
,cups
,WebKit
,meson
...Questionable apps
The module list includes a few apps which are somewhat questionable.
The first is
f-spot
andbanshee
. These were never 100% official, which is maybe fine if the goal is to have a somewhat fuzzy definition of GNOME based on the main areas of activity and interest in the community as opposed to a strict product definition.Of course, if we go down that road, then we might also ask whether other apps should be included, like
shotwell
,geary
andpolari
. (shotwell
is a bit tricky because it became an Elementary app at some point.)One app that I would argue fairly strongly to remove is GIMP and its associated modules (gimp-web and gegl). While GIMP has a historical association with the GNOME project it is fairly independent and has been for some time.
Missing modules
From a cursory inspection, these seem like obvious omissions which it would be good to include:
@felipeborges @neilmcgovern
The text was updated successfully, but these errors were encountered: