Re: Should sensors-applet rather maintained by Debian GNOME Maintainers
On Sun, 09 Feb 2025 at 18:54:25 +0100, Andreas Tille wrote:
> the package sensors-applet came up quite some time as a candidate for
> the Bug of the Day[1]. I hesitated to salvage it since I have no deep
> knowledge into GNOME. I wonder what you consider a good solution. I'd
> volunteer to do the salvaging work if you might create an empty
> repository and leave it for some review. Any other suggestion what
> might be the best course of action is welcome
This appears to be a third-party applet for gnome-panel, which was part of
GNOME 2 but hasn't been part of a normal GNOME installation since around
2010. I don't think the GNOME team in general has enough bandwidth to
take responsibility for additional legacy components.
gnome-panel is still nominally under GNOME team maintenance because
it's part of "GNOME Flashback" (essentially a continuation of GNOME 2
for users who prefer that interface), but the majority of team members
don't use that package and are unlikely to touch it. The majority of
upstream GNOME contributors also don't use, test or maintain gnome-panel
and other Flashback components. In practice gnome-panel's only Debian
maintainer is Dmitry Shachnev, who also maintains gnome-flashback.
Looking at sensors-applet's bug list and upstream homepage, it seems
like it uses various other deprecated things that are on life support
(such as dbus-glib, which has been deprecated for years) and the most
recent upstream activity is Dmitry proposing a patch 5 years ago to
update it for compatibility with newer gnome-panel, which still hasn't
been merged. I think it's safe to say that this is a dead project.
Meanwhile, in Debian, all uploads since 2014 have been NMUs, again mostly
by Dmitry.
sensors-applet is a leaf package with a rapidly declining popcon score,
so I think the only two options worth discussing are adoption by someone
who is actively using GNOME Flashback (in which case they would have to
become its de facto upstream maintainer as well, possibly by forking it),
or removal.
Dmitry has been NMUing it for nearly a decade, so it seems reasonable to
ask him whether he wants to adopt it, but if not, I think RM:RoQA might
be the most appropriate action.
smcv
Reply to: