Search
72 results for “TheEvilSkeleton”
-
Hey, I've been under distress lately due to personal circumstances that are outside my control. I can't find a permanent job that allows me to function, I'm not eligible for government benefits, my grant proposals got rejected, paid internships are quite difficult to find. Essentially, I have no stable monthly income that allows me to sustain myself.
Nowadays, I work mostly on accessibility throughout GNOME as a volunteer, improving the experience of people with disabilities. I helped make the majority of GNOME Calendar accessible with a keyboard and screen reader — still an ongoing effort with !564 and !598 —which is an effort no company ever contributed financially. These merge requests take thousands (literally) of hours to research, develop, and test, which would have been enough to sustain myself for a couple of years if I had been working under a salary.
I would really appreciate any kinds of donations, especially ones that happen periodically to bump my monthly income.
These donations will allow me to sustain myself while allowing me to continue working on accessibility throughout GNOME, potentially even 'crowdfunding' development without doing it on the behalf of the Foundation.
I accept donations through the following platforms:
- “TheEvilSkeleton” on Liberapay: https://liberapay.com/TheEvilSkeleton/donate (free and open-source platform)
- “TheEvilSkeleton” on Ko-fi: https://ko-fi.com/theevilskeleton
- “TheEvilSkeleton” on GitHub Sponsors: https://github.com/sponsors/TheEvilSkeletonBoosts welcome and appreciated.
#Accessibility #a11y #GNOME #GNOMECalendar #MutualAidRequest #MutualAid
-
@TheEvilSkeleton Hey 👋. So there's this problem with the #refine app.
I doesn't identify the cursor theme that I installed. On my previous OS (which was also Fedora), it was able to do it. I believe since I had it on my root directory, that could be a reason.
Could you please look into it ?
-
@TheEvilSkeleton Hey, are you planning some new features for #Refine ?
-
@TheEvilSkeleton @CodedOre And there's this Keyboard option on #gnometweaks, it would be nice if you consider it. Then again, I think it mainly caters to power users. So, not a necessity but nice to have.
-
@TheEvilSkeleton @CodedOre I've to say, if someone enters the #Fedora ecosystem for the first time then, this is the by far the best app to try. It's simple and easy to use. However, the same can also be said about #gnometweaks.
#Refine is almost a complete package. And there's just one thing I would love to get added.
Having a detailed menu rather than a simple popup or you could do a detailed popup. -
CW: Rant about bigotry in "cool" FOSS projects
@TheEvilSkeleton @orowith2os thx for the heads-up.
Sadly that is a common occurence and the only good option I know of is to yeet assholes away...
One of the reasons why I don't want #GNUtils on #OS1337 is because the #FSF readmitted #RMS with 0 consequences!
https://www.youtube.com/watch?v=R2SKenHRhMg via @ncommander
Also #Glibc bricks shit all the time and "just recompile it" doesn't work for a minimalist #embedded-#Linux distro!
-
CW: Rant about bigotry in "cool" FOSS projects
@TheEvilSkeleton @orowith2os thx for the heads-up.
Sadly that is a common occurence and the only good option I know of is to yeet assholes away...
One of the reasons why I don't want #GNUtils on #OS1337 is because the #FSF readmitted #RMS with 0 consequences!
https://www.youtube.com/watch?v=R2SKenHRhMg via @ncommander
Also #Glibc bricks shit all the time and "just recompile it" doesn't work for a minimalist #embedded-#Linux distro!
-
CW: Rant about bigotry in "cool" FOSS projects
@TheEvilSkeleton @orowith2os thx for the heads-up.
Sadly that is a common occurence and the only good option I know of is to yeet assholes away...
One of the reasons why I don't want #GNUtils on #OS1337 is because the #FSF readmitted #RMS with 0 consequences!
https://www.youtube.com/watch?v=R2SKenHRhMg via @ncommander
Also #Glibc bricks shit all the time and "just recompile it" doesn't work for a minimalist #embedded-#Linux distro!
-
@TheEvilSkeleton And then there's #Elive that has "impermutable mode" as a boot mode. That's where all local changes will be lost after a reboot. A nice way to do quick, worry-free tests (Yes even "sudo rm -rf /" :😂 ) and have your system spared and clutter free.
It's for us lazy people who hate back-stepping and repairing.😇 -
@TheEvilSkeleton I mean, this is just a specialization of social media. have you considered checking hashtags like #AppIdea ? if not on Mastodon, definitely on Twitter which is an endless torrent of random musings by consumers
-
Thank you @TheEvilSkeleton for taking the time to make #Meld work with #GNOMEBuilder, so that any #Python + #GTK #GNOME contributor can now easily test and improve that venerable textfiles comparison tool without having to figure out how to build the app by themselves!
This should also make the GTK4 port here easier for anyone to test and contribute to, once it gets rebased: https://gitlab.gnome.org/GNOME/meld/-/merge_requests/105#note_1875728
-
Huge thanks to @maximiliano and @TheEvilSkeleton for reviewing & merging this very long-awaited UX improvement in GNOME Calendar's infinitely scrolling month view: the previous/next buttons (and corresponding keyboard shortcuts) now properly clamp to the beginning of months when switching months! :blobmiou:
See the "before" vs "after" demonstration videos in the merge request: https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/369
#GNOMECalendar #GNOME #UX #productivity #calendaring #planning #OpenSource #FLOSS
-
GNOME Live Coding | Calendar (EN) | 03/03/2026 | Georges Stavracas
https://www.youtube.com/live/Tj5X7YM2Gos?si=LTa-OChY5kkslFgl
#gnome #gnomecalendar #coding #GTK4 #gtk #opensource #libadwaita #linux #foss @gnome @gnome_br @TheEvilSkeleton
-
The (un)fortunate side-effect of me attending the @XOrgDevConf this week is that I found a new #GNOMEShell performance issue to report about scrolling workspaces with a touchpad, because I saw what 60fps feels like on @TheEvilSkeleton's AMD-powered laptop and now I cannot un-see this jank on Intel graphics: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7976
-
@parrot_33
C'est une version vieille de 4 ans et demi. On a réglé plus de 455 bugs depuis, et on continue. Il faut utiliser v50+.Par pitié, cessez d'utiliser Mint et ses versions patchées à l'arrache datant de Mathusalem, on les supplie d'arrêter de packager notre logiciel de cette façon nuisible et jusqu'à présent ils refusent ou feignent l'incompréhension.
Voir:
* https://mastodon.social/@nekohayo/115810821753959688
* https://gitlab.com/linuxmint/pins/mint/gnome-calendar/-/work_items/1
@TheEvilSkeleton @sebsauvage @Natouille -
@parrot_33
C'est une version vieille de 4 ans et demi. On a réglé plus de 455 bugs depuis, et on continue. Il faut utiliser v50+.Par pitié, cessez d'utiliser Mint et ses versions patchées à l'arrache datant de Mathusalem, on les supplie d'arrêter de packager notre logiciel de cette façon nuisible et jusqu'à présent ils refusent ou feignent l'incompréhension.
Voir:
* https://mastodon.social/@nekohayo/115810821753959688
* https://gitlab.com/linuxmint/pins/mint/gnome-calendar/-/work_items/1
@TheEvilSkeleton @sebsauvage @Natouille -
@parrot_33
C'est une version vieille de 4 ans et demi. On a réglé plus de 455 bugs depuis, et on continue. Il faut utiliser v50+.Par pitié, cessez d'utiliser Mint et ses versions patchées à l'arrache datant de Mathusalem, on les supplie d'arrêter de packager notre logiciel de cette façon nuisible et jusqu'à présent ils refusent ou feignent l'incompréhension.
Voir:
* https://mastodon.social/@nekohayo/115810821753959688
* https://gitlab.com/linuxmint/pins/mint/gnome-calendar/-/work_items/1
@TheEvilSkeleton @sebsauvage @Natouille -
@parrot_33
C'est une version vieille de 4 ans et demi. On a réglé plus de 455 bugs depuis, et on continue. Il faut utiliser v50+.Par pitié, cessez d'utiliser Mint et ses versions patchées à l'arrache datant de Mathusalem, on les supplie d'arrêter de packager notre logiciel de cette façon nuisible et jusqu'à présent ils refusent ou feignent l'incompréhension.
Voir:
* https://mastodon.social/@nekohayo/115810821753959688
* https://gitlab.com/linuxmint/pins/mint/gnome-calendar/-/work_items/1
@TheEvilSkeleton @sebsauvage @Natouille -
@parrot_33
C'est une version vieille de 4 ans et demi. On a réglé plus de 455 bugs depuis, et on continue. Il faut utiliser v50+.Par pitié, cessez d'utiliser Mint et ses versions patchées à l'arrache datant de Mathusalem, on les supplie d'arrêter de packager notre logiciel de cette façon nuisible et jusqu'à présent ils refusent ou feignent l'incompréhension.
Voir:
* https://mastodon.social/@nekohayo/115810821753959688
* https://gitlab.com/linuxmint/pins/mint/gnome-calendar/-/work_items/1
@TheEvilSkeleton @sebsauvage @Natouille -
@parrot_33
Point du tout… j'utilise l'application presque exclusivement au clavier quotidiennement, et ça marche, incluant passer d'un champ à l'autre au clavier avec Tab (ou même d'un événement à l'autre avec les touches directionnelles, dans la dernière version), tel que démontré dans la vidéo ci-jointe.#GNOMECalendar met énormément d'efforts pour rendre l'application accessible autant que possible, majoritairement grâce aux contributions de code de @TheEvilSkeleton
-
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, 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
-
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, 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
-
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, 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
-
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, 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
-
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, 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
-
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
-
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
-
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
-
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
-
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