The Linux desktop has a maintenance problem due to the lack of volunteer contributors.
-
@TheEvilSkeleton @Isofruit In my opinion unofficial flatpaks should be more clearly marked as unofficial. I don't think the project should be responsible for community packaging mistakes, and I think users should understand the risk of anything they install.
So no, I think it should get reported to the packager (potentially via flathub). Adding a reporting link to the repo it was built from would be a good thing. Another way to verify ownership.
-
All of this brings me to GNOME Calendar and @linuxmint. For years, we've been dealing with users reporting issues about Linux Mint's package of GNOME Calendar to us, that were either never present or addressed releases ago.
Just a couple of examples:
- https://pouet.chapril.org/@parrot\_33/116374864921983890
- https://vmst.io/@doctroid/116542487573304110
- https://gitlab.gnome.org/GNOME/gnome-calendar/-/work\_items/300
- https://gitlab.gnome.org/GNOME/gnome-calendar/-/work\_items/1562
- https://gitlab.gnome.org/GNOME/gnome-calendar/-/work\_items/1535
- https://gitlab.gnome.org/GNOME/gnome-calendar/-/work\_items/1526
- https://gitlab.gnome.org/GNOME/gnome-calendar/-/work\_items/1429
- https://matrix.to/#/!koZzDOwNHEzEoeuNok:matrix.org/$174759788212004HiyFg:gnome.org?via=gnome.org&via=matrix.org&via=fedora.im
There were a couple of discussions regarding this in the past, in chat, but none of it ended up being productive. Eventually, we got fed up by it and I opened issue #1 on Mint's package of GNOME Calendar — the first issue ever in their package's repository — asking them to remove all links pointing to upstream GNOME Calendar and rebranding the app. This had no response for 6 months, all the while we were still getting bug reports about Mint's broken package. @nekohayo eventually got fed up (again!) and pinged the packager. The packager replied with something completely unrelated and asked which modifications we did not like, completely ignoring our actual request. So, I just told him bluntly that we don't have the time to look through the code just to pinpoint specific issues, so I'll just loosely say "everything", and the only way for us to be happy is if they could rebrand and we can move on.
Then, once again, the packager responds with something unrelated once again, ignoring the essence of my comment, and follows with a whataboutism — "As i said, 46 and 48 are used by millions of people right now in Ubuntu LTS and Debian Stable. Are you going to request Debian and Ubuntu stop shipping GNOME apps?" — in other words, "what about Ubuntu LTS and Debian Stable?" - as a bonus, twisting my words and going from GNOME Calendar to "GNOME apps".
So, once again, I reminded that this is not what the issue is about.
As a side note: no, never would we go after Debian or Ubuntu over this. If the distribution in question is doing its job properly by simply not bothering the people writing the software that they package, then why should we go after them? They are not the ones misleading users into opening in the wrong place, so there is no reason for us to be upset about. In this case, Linux Mint is leeching off of Debian, and pushing their responsibility onto us.
The packager then explains what to do, and redirects us to Debian to take down the package, essentially roping Debian into Linux Mint's problem — all the while completely ignoring the premise of this post. Sure, both Linux Mint and Debian's packages share the same source; however, this is just a technical detail. The actual problem, one that regularly affects us, is that Linux Mint users report issues to us, whereas Debian users report them to Debian.
So, I remind him bluntly that this is not our responsibility as an upstream to fix his problems.
He then suggests to incorporate code upstream to check if the user is running an outdated version or not. In other words, either phoning home, somehow keeping track of releases every 6 months, or something unrealistic.
I lose my patience and hostily tell him that we upstreams don't care about how distributions operate, and reminded, once again, that all we want is for them to rebrand. To which he replied with "If you don't care, then neither do we." — confirming that Linux Mint doesn't care about Debian or even itself as a distribution. Then says "probably requires GNOME Calendar to move away from free licenses" and locks the issue — once again, completely ignoring the essence of this entire issue.
Now they know what the problem is, and have refused to act on it by shoving their responsibilities onto us, but this time intentionally, because that should show upstream for hurting my feelings, never mind the fact that we are the ones doing the hard work, and they are making us do more work. This is the length some distributors will go to abuse people's generosity.
#MaintainerLife #Linux #GNOME #GNOMECalendar #FOSS #OpenSource #FreeSoftware
@TheEvilSkeleton I think this would fit nicely into a blog post! Would also be a lot easier to link to for future reference.
-
All of this brings me to GNOME Calendar and @linuxmint. For years, we've been dealing with users reporting issues about Linux Mint's package of GNOME Calendar to us, that were either never present or addressed releases ago.
Just a couple of examples:
- https://pouet.chapril.org/@parrot\_33/116374864921983890
- https://vmst.io/@doctroid/116542487573304110
- https://gitlab.gnome.org/GNOME/gnome-calendar/-/work\_items/300
- https://gitlab.gnome.org/GNOME/gnome-calendar/-/work\_items/1562
- https://gitlab.gnome.org/GNOME/gnome-calendar/-/work\_items/1535
- https://gitlab.gnome.org/GNOME/gnome-calendar/-/work\_items/1526
- https://gitlab.gnome.org/GNOME/gnome-calendar/-/work\_items/1429
- https://matrix.to/#/!koZzDOwNHEzEoeuNok:matrix.org/$174759788212004HiyFg:gnome.org?via=gnome.org&via=matrix.org&via=fedora.im
There were a couple of discussions regarding this in the past, in chat, but none of it ended up being productive. Eventually, we got fed up by it and I opened issue #1 on Mint's package of GNOME Calendar — the first issue ever in their package's repository — asking them to remove all links pointing to upstream GNOME Calendar and rebranding the app. This had no response for 6 months, all the while we were still getting bug reports about Mint's broken package. @nekohayo eventually got fed up (again!) and pinged the packager. The packager replied with something completely unrelated and asked which modifications we did not like, completely ignoring our actual request. So, I just told him bluntly that we don't have the time to look through the code just to pinpoint specific issues, so I'll just loosely say "everything", and the only way for us to be happy is if they could rebrand and we can move on.
Then, once again, the packager responds with something unrelated once again, ignoring the essence of my comment, and follows with a whataboutism — "As i said, 46 and 48 are used by millions of people right now in Ubuntu LTS and Debian Stable. Are you going to request Debian and Ubuntu stop shipping GNOME apps?" — in other words, "what about Ubuntu LTS and Debian Stable?" - as a bonus, twisting my words and going from GNOME Calendar to "GNOME apps".
So, once again, I reminded that this is not what the issue is about.
As a side note: no, never would we go after Debian or Ubuntu over this. If the distribution in question is doing its job properly by simply not bothering the people writing the software that they package, then why should we go after them? They are not the ones misleading users into opening in the wrong place, so there is no reason for us to be upset about. In this case, Linux Mint is leeching off of Debian, and pushing their responsibility onto us.
The packager then explains what to do, and redirects us to Debian to take down the package, essentially roping Debian into Linux Mint's problem — all the while completely ignoring the premise of this post. Sure, both Linux Mint and Debian's packages share the same source; however, this is just a technical detail. The actual problem, one that regularly affects us, is that Linux Mint users report issues to us, whereas Debian users report them to Debian.
So, I remind him bluntly that this is not our responsibility as an upstream to fix his problems.
He then suggests to incorporate code upstream to check if the user is running an outdated version or not. In other words, either phoning home, somehow keeping track of releases every 6 months, or something unrealistic.
I lose my patience and hostily tell him that we upstreams don't care about how distributions operate, and reminded, once again, that all we want is for them to rebrand. To which he replied with "If you don't care, then neither do we." — confirming that Linux Mint doesn't care about Debian or even itself as a distribution. Then says "probably requires GNOME Calendar to move away from free licenses" and locks the issue — once again, completely ignoring the essence of this entire issue.
Now they know what the problem is, and have refused to act on it by shoving their responsibilities onto us, but this time intentionally, because that should show upstream for hurting my feelings, never mind the fact that we are the ones doing the hard work, and they are making us do more work. This is the length some distributors will go to abuse people's generosity.
#MaintainerLife #Linux #GNOME #GNOMECalendar #FOSS #OpenSource #FreeSoftware
@TheEvilSkeleton @linuxmint @nekohayo
I have no horse in this race but it seems to me that the Mint dev was reasonable. He explained the same issue exists in Debian and Ubuntu (i.e. the About dialogue links to the Gnome Calendar repo) and he offered to patch the dialogue in Mint.
You then said you weren't interested in the "intricacies" and repeated your demand that they fork Calendar. I get your frustration but I understand why they closed the issue.
-
@TheEvilSkeleton @reflex From a purist perspective? Whoever packages the code is to be the person that gets to triage, that was where I was going with what I wrote.
So in the case of unofficial flathub packages, whoever makes those packages is imo supposed to be the one that checks if they're just outdated or still true.
From a pragmatist standpoint, if that particular flatpack is known to package new releases quickly, you could again make the case that it'd be valid to go to upstream.
-
@TheEvilSkeleton @linuxmint @nekohayo okay, so to be consistent, I expect you to now file issues and be hostile towards every LTS distro, that ships GNOME - Ubuntu, Debian, openSUSE Leap.
You really don't see how stupid this is? The whole POINT of LTS distributions is to ship outdated packages. That's how they operated FOR DECADES. You have NO RIGHT to request removal of a package, or rebranding it, simply because you don't feel like dealing with bug reports coming from LTS
This is so stupid
@leniwcowaty A distro is in general responsible to fix bugs downstream, that are fixed upstream. Be it by shipping new releases or backporting fixes.
A bug, not present in upstream is considered a downstream issue. Pointing to upstream feels a useless. How should upstream even deal with it, if downstream doesn't Backport the fixes to begin with?
-
@TheEvilSkeleton I think this would fit nicely into a blog post! Would also be a lot easier to link to for future reference.
@bragefuglseth @TheEvilSkeleton If you do decide to write one (or one about distro-packaging in general), feel free to send me a message, I have an additional argument that I'm happy to share (I don't want to share it before, it would ruin the fun :)).
-
@Isofruit at the beginning, I actually wanted to cooperate, but after that first comment of his, it was pretty clear to me that he didn't even spend 5 minutes to read the actual issue, and instead cherry picked parts of messages. Like, that's what he does later too
@TheEvilSkeleton I'm not sure if my work environment hardened me in that direction or if it's just because I'm reaching my mid thirties and am thus basically dead, but I think being more relaxed would've been the solution.
Just repeatedly forcing the topic back to the point - and ideally from the jump not giving them the chance to get distracted.
IIRC Sebastian Wick similarly had an issue with a PR where imo he escalated too quickly (if you follow him on Mastodon you'll know).
-
@m @TheEvilSkeleton well, so what? Should we outlaw LTS distros, on the offchance, that their user will file a bug report regarding an older version? Maybe GNOME apps should refuse to install on anything except Arch?
I'm a sysadmin. On a daily basis I get issue reports regarding systems that run for example Debian 12. For stuff that is fixed in latest Arch. Should I now force the entire company to switch their servers to Arch, because I don't feel like dealing with these issues?
@leniwcowaty Knowingly distributing an old release of an app to a large, tech-illiterate audience, with hundreds of known bugs, pretending it’s the latest and greatest, and the support link pointing to the upstream issue tracker, is not “Long Term Support”. I’d say it’s the opposite, because this kind of abuse is actually damaging to the long-term survival of the upstream project.
If I were a GNOME Calendar developer, I’d be furious.
-
@TheEvilSkeleton @reflex From a purist perspective? Whoever packages the code is to be the person that gets to triage, that was where I was going with what I wrote.
So in the case of unofficial flathub packages, whoever makes those packages is imo supposed to be the one that checks if they're just outdated or still true.
From a pragmatist standpoint, if that particular flatpack is known to package new releases quickly, you could again make the case that it'd be valid to go to upstream.
@Isofruit @TheEvilSkeleton I still think the packager is responsible for the initial triage. Packaging mistakes are a thing and sometimes they won't notice new dependencies or other configuration changes. It should not be pushed upstream until they are certain they did everything right.
-
@m @TheEvilSkeleton well, so what? Should we outlaw LTS distros, on the offchance, that their user will file a bug report regarding an older version? Maybe GNOME apps should refuse to install on anything except Arch?
I'm a sysadmin. On a daily basis I get issue reports regarding systems that run for example Debian 12. For stuff that is fixed in latest Arch. Should I now force the entire company to switch their servers to Arch, because I don't feel like dealing with these issues?
@leniwcowaty @m @TheEvilSkeleton
From what I can tell, the root problem is resources burnt and reputation damage created by users getting old software.
Imo there's a fair case that the one who packages is to be the first line of support that maybe informs upstream.
To solve that problem there are many options. Adjusting the support link, branding, only shipping the flatpak etc. would be some possibilities.
Which way to go imo would be up to a calm discussion between distro and upstream, no?
-
P pixelate@tweesecake.social shared this topic
