The Linux desktop has a maintenance problem due to the lack of volunteer contributors. One reason for this is that upstream projects are at the mercy of downstream distributions, who have the final say.

As an upstream contributor, you have no choice but to meticulously plead for any reasonable request to be granted by downstreams, treating them as if they were some kind of deity. Not doing so with the utmost respect can get you on their naughty list, which they can then use against you just because they can, and because the license allows it โ€” they will even play the 'you chose the wrong license' card when they have nothing else to say.

The idea that the distribution model expects users to report issues to downstream is no longer valid. In reality, many distributions advertise themselves as user-friendly. Users of these distributions are unaware of the distribution model, so they report issues to upstream rather than downstream. Often, these bug reports and feature requests have already been solved in previous releases, so the upstream has to regularly triage and close duplicate and outdated bug reports. This creates an additional burden for them because they end up spending their limited volunteer time managing these issues when it should be the responsibility of the downstream.

Whenever the upstream project reaches out to the downstream distribution and asks for a change, the response is usually with the downstream pretending to look for a solution by first asking for a list of bugs to be found and compiled, essentially shifting the responsibility back to upstream to start a virtual machine just to test the package and find bugs. If upstream objects to this absurd request, downstream proposes unrelated or unrealistic 'solutions', such as adapting the issue tracker or switching to a proprietary license, just to avoid doing any actual work. Eventually, when the tone of the upstream project changes, the downstream makes remarks on that tone and starts acting like they are the reasonable one; they end the discussion and continue misleading users into reporting to the upstream project, but this time intentionally and out of spite, just to continue avoiding taking responsibility and accountability.

#MaintainerLife #FOSS #OpenSource #FreeSoftware #Development #Linux

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:

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, 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

Parrot (@[email protected])

Attached: 1 image @[email protected] @[email protected] @[email protected] @[email protected] Alors nous n'avons pas la mรชme version, moi j'ai la 41.2 de Linux Mint

Mastodon Chapril

@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

@TheEvilSkeleton @linuxmint @nekohayo if you tried that with Ubuntu or openSUSE you would just get laughed at and the issue would be locked without any further discussion. But now you feel strong and powerful picking at a smaller project. Good job you. And then you wonder, why people call GNOME development team toxic...
TheEvilSkeleton ๐Ÿ‡ฎ๐Ÿ‡ณ ๐Ÿณ๏ธโ€โšง๏ธ (@[email protected])

Hmm... So, requiring a [sandbox](https://github.com/bottlesdevs/Bottles/pull/3583) to run @[email protected] is considered evil and proprietary software, but [patching it to remove the donate button without updating support links](https://build.opensuse.org/projects/openSUSE:Factory/packages/Bottles/files/dont-support.patch?expand=1) is considered fine? Uh huh... Edit: Please keep in mind that this was not a decision made by the entire openSUSE community. This is addressed to the people who authored and accepted the patch. Update: The patch is [no longer being applied](https://build.opensuse.org/request/show/1232727).

Treehouse Mastodon
@TheEvilSkeleton that's different. And if you don't see difference, then you very nicely show your hostility towards FOSS in general
@leniwcowaty @TheEvilSkeleton you literally said that to a FOSS dev that did more for FOSS than you ever could achieve

@leniwcowaty @TheEvilSkeleton Different how? Both are projects shipping downstream versions that are broken and dumping the blame on upstream and running for cover.

Except in mints case, the version of software they ship is both broken *and* an old version to their much more naive audience, who all seem to refuse to test newer versions on #flathub before complaing for some reason when pointed out how old the software they are using is.

Also (and this is not a defense of there wrongdoings at all, because they have both fucked up in the past with their distro distribution) Ubuntu/Suse parent companies hire people to work on GNOME, same with a lot of Debian contributors. Mint by comparison has done jackshit to help upstream, except dump more bugs on our table.

But sure, we are just evil and toxic for reminding people that we don't have infinite hours of the day to work on things none of us are paid to work on, so would like downstreams that do nothing but add more work on us with no gain to pretty please not do that instead. For someone who pretends to care about FOSS you have 0 interest in actually helping the people who make it.

@leniwcowaty @TheEvilSkeleton oh and btw, if you think this is something I only critize mint or fedora for - no. I have had beef with all downstream distros at one point or another (like NixOS for the recent high score situation (https://mk.nyaa.place/notes/am2ivjwats8902qh) and Suse with the bottles situation, and Ubuntu with the very existence of snap).

Because for some reason, downstream distros just have this idea they can do whatever they want, and just make it upstreams problem to collect the bugs like pokemon, because they simply can not except no from the people who make their own software to distribute it properly.

Alice :neocat_flag_transbian: (@alice)

@[email protected] or nixos shipping highscore which hasn't had a stable release at all - it's pre-alpha software rn with a bunch of cores broken, no less - some worked when they packaged it and then broke (unstable software may change in unpredictable ways without consideration for downstreams? no shit) and some just never worked and they just didn't test them and then a nixos person wants me to "compromise". Like no, I don't want them to compromise. I want them to stop doing this shit that they should have never been doing in the first place I already didn't have a lot of respect for nixos, but now I consider it manjaro-tier bad RE: @[email protected] Arch Linux shipping Krita 6.0.1 (beta) marked as a "dev build" and which crashes when I try to open the color wheel with my tablet makes me agree with you strongly. RE: ...

Nyaa~ Place

@zoeyTheWitch @leniwcowaty @TheEvilSkeleton So which distro does this perfectly?

You are being a bit uncharitable towards a project which has made desktop Linux accessible to a large number of people.

@shakil_tcs @leniwcowaty @TheEvilSkeleton IMO - basically none except for the build stream distros like GNOME OS/KDE Linux, but some other distros do get closer to working with upstream to resolve issues, like the UBlue distros. I am sure mint's developers have done this at some point, but unfortunately I have yet to see this.

I should clarify I am not picking on just Mint for doing things like this. This problem of downstreams wasting upstream projects time and shipping broken software to their users goes beyond just Linux Mint, this is a structural and social problem in the Linux desktop.

@TheEvilSkeleton and besides - please answer me, why is Mint the ONLY distro, which you try to force to remove/rebrand GNOME Calendar, based on the fact, that it ships outdated version (which is expected by an LTS distro)?
Why didn't you file such request for Ubuntu LTS? For Debian? They also package GNOME Calendar 46 and 48 respectively. Their users experience the same bugs as Mint users. And I bet, their users also come to the upstream to file bug reports. Why are you ONLY pursuing Mint?
@leniwcowaty @TheEvilSkeleton

because most of the outdated issues come from mint users, because this distro attracts more beginners

@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.

@jwh @leniwcowaty Why not starting with a first little step and see how the support burden changes?

Meaning: Update the link and see how the workload changes or not. This keeps the downstream patchset minimal and results can be observed. If the amount of requests drop to the Debian level things should be fine.

If it is not sufficient further steps can be considered.

@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?

@Isofruit @TheEvilSkeleton @leniwcowaty

yeah thats what TES tried
@TheEvilSkeleton @leniwcowaty @Isofruit

tbh i feel like theevilskeletons issue really ought to be fixed at the license level, but surely

"i maintain this software in my free time, your setup is making me burn out, please change your setup" is a reasonable ask

honestly i havent thought that much about how being paid vs not being paid changes the dynamic so much, but it really does
@m @TheEvilSkeleton @leniwcowaty I really do not like the idea of changing the license to be the solution. To me this still looks like something that should be solved collaboratively (though that train likely left the station by now given how heated things have become at this point).
@leniwcowaty @m @TheEvilSkeleton In my opinion, for gui apps not tied to the shell components, official flatpaks should be the only way to go.
@leniwcowaty genuine question, have you read the entirety of my post? I explain why I don't take issue with Debian and Ubuntu
@TheEvilSkeleton @leniwcowaty They are just angry person defending their fav distro. They have no interest in actual discussion
@leniwcowaty @TheEvilSkeleton They clearly and repeatedly stated that most issues about outdated versions are logged by Mint users.

@leniwcowaty @TheEvilSkeleton @linuxmint @nekohayo There is a difference between shipping outdated packages and offloading your issues to upstream. Distributions can (and should) ship outdated software with changed branding.

> You have NO RIGHT to request removal of a package

Statements like this make me seriously question whether I should publish any of my work under an open source license, which I think is a rather sad thing :(

@FineFindus @TheEvilSkeleton @linuxmint @nekohayo ah yes, and if a distro changes the branding, the developer will come after them for changing the branding. Because how could they steal our project?! They should give credits, link to the upstream! And don't tell me, this doesn't happen...
@leniwcowaty @TheEvilSkeleton @linuxmint @nekohayo I doubt it, considering they are explicitly asked to change branding.
Once again there is also a difference between having 'GNOME Calendar' with a link to the GNOME issuetracker and a forked 'Mint Calendar' which has a credit line in the about section.

@leniwcowaty @FineFindus @TheEvilSkeleton @linuxmint @nekohayo I mean, it's still software licensed under GPL, anyone is free to fork. With Calender it happened many times before and will happen again. It's fine, that's how free software lives.

There are people butthurt over forking their software, but I doubt you'll see them in GNOME.

@leniwcowaty @FineFindus @TheEvilSkeleton @linuxmint @nekohayo This take is misinformed about how copyright works, trademarks work, and licenses work

The short summary is:
- yes, stealing someone's work without credit is plagiarism and possibly copyright infringement
- at the same time, having a derivative product that uses the upstream project's trademarks to confuse customers and imply a level of endorsement or support is possibly trademark infringement

Both can be true at once

@leniwcowaty @FineFindus @TheEvilSkeleton @linuxmint @nekohayo

You do realize just because something is FOSS doesn't mean it's automatically a free for all for the trademarks and branding correct? The code is FOSS and can be modified and redistributed to your hearts extent. Its fully within Skellys and Gnomes right to request you to stop using their trademarks. It'll be OBS and Fedora all over again. How long before one of these upstream projects take a distribution to court and finally put them in their place.

@FineFindus yeah :(. There's a reason why I've progressively become more vocal and hostile towards these kinds of people, especially those in position of power

@leniwcowaty

@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 like a useless action. How should upstream even deal with it, if downstream doesn't Backport the fixes to begin with?

@TheEvilSkeleton @nekohayo It's weird to me that Linux Mint seems to always be the recommendation for beginners. I hope GNOME OS becomes stable soon, such that it may seriously start getting pushed as the beginner-friendly distro.
@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 :)).

@FineFindus @bragefuglseth this is actually funny because I've been meaning to write an article about this, but later reconsidered it: https://gitlab.com/TheEvilSkeleton/theevilskeleton.gitlab.io/-/work_items/84

Maybe I should re-reconsider it...

To what length will distributions go to hurt upstream? (#84) ยท Issues ยท Hari Rana / theevilskeleton.gitlab.io ยท GitLab

https://social.treehouse.systems/@TheEvilSkeleton/113676105047314912

GitLab

@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 @linuxmint @nekohayo

I honestly wish an upstream project would take one of these distributions to court for trademark violation one of these days. It's been far too long where distributions think they can do whatever they want.

@TheEvilSkeleton I would have assumed @linuxmint 's version would be a fork anyway to keep it gtk3 or adwaita free?

I use mint on my daughters machine (she picked cinnamon out of the options I gave her) but I would never assume a gnome app issue needed to be reported to GNOME because they are all out of date.

@TheEvilSkeleton Would it make more sense to put end user support on the distros? Reports go there, they triage them and anything not fixed at the upstream source gets a bug filed by the distro, anything already fixed upstream they integrate the fix with their distro?
@reflex @TheEvilSkeleton That would make sense and while I did not pay too much attention until around... 2 years ago, I swear that used and still is to some degree the case.
@Isofruit @TheEvilSkeleton To my mind direct support by the upstream only makes sense at best on a rolling release where the user is staying up to date.

@reflex @TheEvilSkeleton From a purist point of view, only flatpaks are valid, everything else should go through the distro - even if it's arch.

From a pragmatist standpoint you could make the case that arch, tumbleweed etc. *should* be up to date enough. But at that point you can also include Ubuntu or Fedora on their freshest version since they shouldn't be too far behind with those... (Ubuntu LTS is where things start getting funky)

@Isofruit @TheEvilSkeleton For apps like Bottles I agree, if they aren't on the flatpak they are unsupported per the project. For other packages that isn't necessarily the case, I was referring to them on this.

Personally I think everything reasonable should be moved to a containerized format. It's the only thing Snap does better than Flatpak about.

@Isofruit I wonder, do you consider unofficial packages on Flathub valid? Personally, it makes total sense to have users report through Flathub's issue tracker before reporting to upstream if it's unofficial

@reflex

@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.

@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.

Me end user.
Me install software.
Software do bad.
Me look in package metadata for support instructions.

Today:

Me find nothing.
Me read page in manual... [Just kidding]
Me search interwebs for software.
Me find project.
Me post message to forum / issue tracker / etc. saying, "It not work. You fix."
Unpaid dev move to island, learn to fish.

Today in other universe:

Me follow support instructions.
Me submit detailed report with right tool to right place based on who packaged the software.

@TheEvilSkeleton We agree on a lot of things and sure, generally what you write here comes from a fair perspective, but ultimately, I don't think that matters.

Upstream has a problem and they need to work together with downstream to fix it. That will require collaboration, including the *tone* of collaboration. Framing issues as a shared problem to be solved together. You saw me write that in the other thread: No amount of being on the right side here will get you past that fact.

@TheEvilSkeleton Impart onto them the human cost this has if need be. Give them numbers to make them understand the problem and thus be your ally in solving it, rather than demanding solutions.

Show them that this caused a X support request in the past while, wasting Y hours.

If being confronted with a problem they created and its effects fails to convince them to help, then it's entirely fair to publicly call them out on it. That'll likely give you more public support than what we saw earlier

@Isofruit https://social.treehouse.systems/@TheEvilSkeleton/116557125069876147

As for "wasting Y hours", I don't think any of us keeps track of how much time it wastes. Even then, it's not just the time, but the energy too. Making volunteers do something they don't want is a significant misuse of their energy.

@TheEvilSkeleton I don't think you need to be diligent there. A simple "Issues x 2h" for a rough estimate that isn't completely outlandish would do the trick.

The only thing I'm looking at here, is what I think to be the best way for you to get what you want, since I understand your plight.

And from that perspective I can only arrive that the tone is what killed it. It is understandable that things went the way they did, your position is understandable, but it is just not *effective*.

@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).