#maintainerlife — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #maintainerlife, aggregated by home.social.
-
@adilarif
I don't know about whether there is actual corporate backing here, but learning that J-M Brummer developed "Stamp" in his own corner for two years without any fanfare, I can imagine the words of Abram Tarasov echoing here:"Jan-Michael…
is a man of focus…
commitment…
and sheer. fucking. will. 🚬🤨🤌He once killed 3 memleaks in a bug…
…with a fökkin' ptrace! 😳✏️" -
@adilarif
I don't know about whether there is actual corporate backing here, but learning that J-M Brummer developed "Stamp" in his own corner for two years without any fanfare, I can imagine the words of Abram Tarasov echoing here:"Jan-Michael…
is a man of focus…
commitment…
and sheer. fucking. will. 🚬🤨🤌He once killed 3 memleaks in a bug…
…with a fökkin' ptrace! 😳✏️" -
Yes, I closed your issue in 2mins. But considering it just had the title "Not working" and no body it really wasn't worth anymore effort since the service is up and running just fine...
-
Yes, I closed your issue in 2mins. But considering it just had the title "Not working" and no body it really wasn't worth anymore effort since the service is up and running just fine...
-
I love the subscribe to tags feature in gitlab, and having team mates that properly tag MRs and issues. I come back from a week off and my email is mostly filled with *on-topic* emails I likely want to look at.Thanks everybody for that.
-
I love the subscribe to tags feature in gitlab, and having team mates that properly tag MRs and issues. I come back from a week off and my email is mostly filled with *on-topic* emails I likely want to look at.Thanks everybody for that.
-
I was kinda burnt-out at the end of last year. I felt like there's so much to do, yet too little to to tackle anything.
For the past two months, I've been experimenting with the "1% rule": instead of few heavy lifts, I did smaller things but like every day. -
I was kinda burnt-out at the end of last year. I felt like there's so much to do, yet too little to to tackle anything.
For the past two months, I've been experimenting with the "1% rule": instead of few heavy lifts, I did smaller things but like every day. -
I was kinda burnt-out at the end of last year. I felt like there's so much to do, yet too little to to tackle anything.
For the past two months, I've been experimenting with the "1% rule": instead of few heavy lifts, I did smaller things but like every day. -
I was kinda burnt-out at the end of last year. I felt like there's so much to do, yet too little to to tackle anything.
For the past two months, I've been experimenting with the "1% rule": instead of few heavy lifts, I did smaller things but like every day. -
I was kinda burnt-out at the end of last year. I felt like there's so much to do, yet too little to to tackle anything.
For the past two months, I've been experimenting with the "1% rule": instead of few heavy lifts, I did smaller things but like every day. -
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
-
If those conditions are met, the dialog could also automatically show an educational infobar saying, "Issues must be reported to the package distributor instead of upstream, as the version is beyond the support lifecycle of this application's actual developers (upstream)", and to please leave us alone because a majority of #FreeSoftware devs have a thousand-yards stare and want to retire to a goat farm upstate and become solarpunks or something :blobsweats:
-
If those conditions are met, the dialog could also automatically show an educational infobar saying, "Issues must be reported to the package distributor instead of upstream, as the version is beyond the support lifecycle of this application's actual developers (upstream)", and to please leave us alone because a majority of #FreeSoftware devs have a thousand-yards stare and want to retire to a goat farm upstate and become solarpunks or something :blobsweats:
-
It'd be great if #GTK & #libadwaita's About dialogs had a property for "Months of support per version", which would check the app's running version against its "date" field in the AppData metainfo.xml and hide the "Website" & "Report an Issue" buttons if it's too old.
Thus upstream devs could avoid being the externalized cost of free "LTS" distros (users reporting issues about ancient versions) without being accused of being anti #FLOSS (like in https://gitlab.com/linuxmint/pins/mint/gnome-calendar/-/work_items/1)
-
It'd be great if #GTK & #libadwaita's About dialogs had a property for "Months of support per version", which would check the app's running version against its "date" field in the AppData metainfo.xml and hide the "Website" & "Report an Issue" buttons if it's too old.
Thus upstream devs could avoid being the externalized cost of free "LTS" distros (users reporting issues about ancient versions) without being accused of being anti #FLOSS (like in https://gitlab.com/linuxmint/pins/mint/gnome-calendar/-/work_items/1)
-
PSA to GNOME Calendar contributors: we just merged a pair of refactoring branches that rearchitect tons of code to eliminate a whole class of problems in the backend and the views: https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1496
This unfortunately means many contributors with pending merge requests will have to manually rebase and deconflict their code on top of the latest main branch. It may feel like reloading a Patlabor's revolver, but should be worth it.
-
PSA to GNOME Calendar contributors: we just merged a pair of refactoring branches that rearchitect tons of code to eliminate a whole class of problems in the backend and the views: https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1496
This unfortunately means many contributors with pending merge requests will have to manually rebase and deconflict their code on top of the latest main branch. It may feel like reloading a Patlabor's revolver, but should be worth it.
-
PSA to GNOME Calendar contributors: we just merged a pair of refactoring branches that rearchitect tons of code to eliminate a whole class of problems in the backend and the views: https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1496
This unfortunately means many contributors with pending merge requests will have to manually rebase and deconflict their code on top of the latest main branch. It may feel like reloading a Patlabor's revolver, but should be worth it.
-
PSA to GNOME Calendar contributors: we just merged a pair of refactoring branches that rearchitect tons of code to eliminate a whole class of problems in the backend and the views: https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1496
This unfortunately means many contributors with pending merge requests will have to manually rebase and deconflict their code on top of the latest main branch. It may feel like reloading a Patlabor's revolver, but should be worth it.
-
PSA to GNOME Calendar contributors: we just merged a pair of refactoring branches that rearchitect tons of code to eliminate a whole class of problems in the backend and the views: https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1496
This unfortunately means many contributors with pending merge requests will have to manually rebase and deconflict their code on top of the latest main branch. It may feel like reloading a Patlabor's revolver, but should be worth it.
-
@cassidy @sri @hbons
In the world of constantly-improving FLOSS apps, negative reviews absolutely need a limited lifespan IMHO, because they will never reflect reality in anything beyond short-term shelf life: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2181 -
@cassidy @sri @hbons
In the world of constantly-improving FLOSS apps, negative reviews absolutely need a limited lifespan IMHO, because they will never reflect reality in anything beyond short-term shelf life: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2181 -
@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 -
PSA: following the example from various other projects within GNOME (such as Loupe and libadwaita), GNOME Calendar now explicitly forbids AI-generated contributions, with the same policy: https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/725
We honor the exquisite art of organic homegrown code made with care and a willingness to learn the craft, and want to protect the time of people who help review merge requests.
#MaintainerLife #FreeSoftware #FLOSS #OpenSource #GNOMECalendar #NoAI #aislop #genAI #LLM #GNOME #libadwaita
-
PSA: following the example from various other projects within GNOME (such as Loupe and libadwaita), GNOME Calendar now explicitly forbids AI-generated contributions, with the same policy: https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/725
We honor the exquisite art of organic homegrown code made with care and a willingness to learn the craft, and want to protect the time of people who help review merge requests.
#MaintainerLife #FreeSoftware #FLOSS #OpenSource #GNOMECalendar #NoAI #aislop #genAI #LLM #GNOME #libadwaita
-
As someone trying to keep fellow FLOSS maintainers from burning out, I believe I speak for many Free & Open-Source software folks out there when I say that this scene from John Carpenter's "The Thing" (1982) reflects the current vibe towards non-trivial inbound merge requests from people we don't already know…
#MaintainerLife #FLOSS #FOSS #FreeSoftware #OpenSource #GenAI #LLM #AI #Copilot #Claude #ChatGPT #AIslop #DeadInternet #capitalism #enshittification #TheThing
-
As someone trying to keep fellow FLOSS maintainers from burning out, I believe I speak for many Free & Open-Source software folks out there when I say that this scene from John Carpenter's "The Thing" (1982) reflects the current vibe towards non-trivial inbound merge requests from people we don't already know…
#MaintainerLife #FLOSS #FOSS #FreeSoftware #OpenSource #GenAI #LLM #AI #Copilot #Claude #ChatGPT #AIslop #DeadInternet #capitalism #enshittification #TheThing
-
An example of a 10-years-old feature request in GNOME Calendar that has been superseded by the combination of 5 other UX improvements, to the point where I am comfortable putting the original ticket to rest until a new technological development comes up: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/46#note_2686910
Same with this 2.5-years-old feature request of mine (which has now been superseded by two of those UX enhancements): https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1072#note_2686968
-
An example of a 10-years-old feature request in GNOME Calendar that has been superseded by the combination of 5 other UX improvements, to the point where I am comfortable putting the original ticket to rest until a new technological development comes up: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/46#note_2686910
Same with this 2.5-years-old feature request of mine (which has now been superseded by two of those UX enhancements): https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1072#note_2686968
-
In a client's bookshelf, I have found a book for my fellow #GNOME developers 😶🌫️
-
In a client's bookshelf, I have found a book for my fellow #GNOME developers 😶🌫️
-
Some people are a bit *too* excited about the upcoming jQuery 4.0 release.
#jquery #maintainers #FLOSS #maintainerlife #OpenSourceMaintainer
-
Some people are a bit *too* excited about the upcoming jQuery 4.0 release.
#jquery #maintainers #FLOSS #maintainerlife #OpenSourceMaintainer
-
To celebrate the new year, I, too, have decided to partake in the traditional GNOME bugfixing technique of… deleting code to make things work :blobmiou: (it turns out that some parts of calendaring standards specifications are pretty weird, and most other apps couldn't even render the alarm types we created)
https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/680
-
To celebrate the new year, I, too, have decided to partake in the traditional GNOME bugfixing technique of… deleting code to make things work :blobmiou: (it turns out that some parts of calendaring standards specifications are pretty weird, and most other apps couldn't even render the alarm types we created)
https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/680
-
FLOSS #MaintainerLife public service advisory:
If you're filing a potential bug upstream in #GNOME, particularly on rapidly-improving apps like GNOME Calendar, please test the latest version, unmodified by third-parties. #Flatpak helps.Don't come at me with a 4-years-old version cowboy-patched against our will by #Linux distros like Mint; I will send you downstream, like this: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1526#note_2640160
#FreeSoftware #OpenSource #QA #bugreporting #LinuxMint #Debian #Ubuntu #LTS #GNOMECalendar
-
FLOSS #MaintainerLife public service advisory:
If you're filing a potential bug upstream in #GNOME, particularly on rapidly-improving apps like GNOME Calendar, please test the latest version, unmodified by third-parties. #Flatpak helps.Don't come at me with a 4-years-old version cowboy-patched against our will by #Linux distros like Mint; I will send you downstream, like this: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1526#note_2640160
#FreeSoftware #OpenSource #QA #bugreporting #LinuxMint #Debian #Ubuntu #LTS #GNOMECalendar
-
A six-years-old heisenbug in GNOME Calendar's week view, demonstrated in the picture below, just got fixed thanks to one oddly specific duplicate bug report's reproduction instructions and This One Weird Trick 1-character patch by @KekunPlazas … The Cause May Surprise You!™ :thinkerguns:
-
A six-years-old heisenbug in GNOME Calendar's week view, demonstrated in the picture below, just got fixed thanks to one oddly specific duplicate bug report's reproduction instructions and This One Weird Trick 1-character patch by @KekunPlazas … The Cause May Surprise You!™ :thinkerguns:
-
Stephen Chow's "Kung Fu Hustle" movie is a great metaphor for "FLOSS middleware & apps" software development communities sometimes, especially the amount of animosity #GNOME developers have to cope with.
In this scene we see:
1. A crowd of users complain, the signal-to-noise ratio deteriorates
2. Upstream dev tells them to shut up & send a MR
3. Two distro packagers try to "fix" the issue in their cornerhttps://www.youtube.com/watch?v=v7NMH78ex0E
#MaintainerLife #OpenSource #FreeDesktop #Flatpak #Linux #KungFu
-
Stephen Chow's "Kung Fu Hustle" movie is a great metaphor for "FLOSS middleware & apps" software development communities sometimes, especially the amount of animosity #GNOME developers have to cope with.
In this scene we see:
1. A crowd of users complain, the signal-to-noise ratio deteriorates
2. Upstream dev tells them to shut up & send a MR
3. Two distro packagers try to "fix" the issue in their cornerhttps://www.youtube.com/watch?v=v7NMH78ex0E
#MaintainerLife #OpenSource #FreeDesktop #Flatpak #Linux #KungFu
-
In the past few years of triaging issues for #GNOMECalendar, I noticed it's often the same three distros from which I keep hearing the weirdest things…
This is the 3rd time someone complains that dark mode is not working, and I don't know how that's even possible (elsewhere, it Just Works): https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1390
I don't know what y'all do with Endeavor OS and Nix OS, but it sure sounds like playing #Linux on "Ultra Violence" difficulty :blobcatcoffee:
-
In the past few years of triaging issues for #GNOMECalendar, I noticed it's often the same three distros from which I keep hearing the weirdest things…
This is the 3rd time someone complains that dark mode is not working, and I don't know how that's even possible (elsewhere, it Just Works): https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1390
I don't know what y'all do with Endeavor OS and Nix OS, but it sure sounds like playing #Linux on "Ultra Violence" difficulty :blobcatcoffee:
-
Sometimes when the review backlog gets crazy you wonder if you might ever get back on top again...
-
…part 2 of 2: ⬇️
My analogy for #FOSS software project maintainership, especially in complex apps & languages, is:
You're the head mecha engineer for Alstom who built an automated maglev train for the city's free public transit.
Through months/years in operation, commuters report small issues or outages on the billboard. 2 of them are city maintenance techs who occasionally fix a wagon's door.
You wonder why other passengers don't train as techs.