My comment was a joke, obviously. However, it's not that difficult to provide that kind of support and bugfixing. It's not like developing something new.
> Also wouldn't most devs much rather fix bugs in an existing app than add features?
No, for a few reasons: 1) it's often tedious work 2) often the bug has been around a long time and nobody's really noticed or cared, so how important could it be? 3) organizations rarely reward this work.
> It seems like the problem you are trying to solve is potential users quickly dismissing projects with too many open issues.
No. The issue I am talking about is that there is no clear separation between things which must be addressed (bugs) and things which don't (feature requests). There is no possible way I could have made that more clear. I have repeated this in almost every comment on this topic. You seem to be intentionally misunderstanding me at this point.
> "Add an Include directive for ssh_config(5) files"
Edit: my comment wasn't intended as negative, more a pleasant surprise. How often does "primarily a bug fix" release include functionality thats been requested by users for literally years?
honestly I've offered multiple times to implement features/fix bugs. they never respond. that argument doesn't hold weight anymore when dealing with gnome.
Client: "What do you mean it will cost X money and Y time to fix this trivial bug/feature in our App? And whats this babbling about having to upgrade at least a dozen frameworks? I just want this simple thing changed, not have my entire App rebuild. Last time you did that everything else broke and it took forever to get all the new bugs sorted."
I've had a number of devs, when receiving feedback, tell me that I should instead seek out their bug tracker, register with their feedback system, open a support ticket, give detailed instructions about how to identify and fix my problem, and then wait for a decision about how I'm wrong.
There's no such thing as a major bugfix release. Every major update introduces more bugs than it fixes, and Sonoma is no exception to that hard rule. Which bugs were fixed? I've personally filed multiple new bugs against Sonoma.
I wrote about this in my previous comment: "It's not because of the .0 releases, which were very buggy like any .0 releases"
The comment was in response to parent's stated complaint, namely having to wait for someone else to resolve issues with popular packages being broken after an update, which has been the experience of more than one user.
> broken development practices and the developers focusing on adding more features rather than working through the issues
Both of those problems are easily attributed to a lack of funding. Fulfilling feature requests generates money, fixing bugs does not. When you can only afford to spend 10 hours a week on a project, you're going to end up cutting corners to work around those time limits.
> The moment you allow bugs, you can't ensure backwards compatible changes.
I'm not sure what this even means, unless you're talking of the joke of "someone depended on the bug"?
A bug, by its very definition, means code that doesn't behave as the documented interface description states. Fixing bugs means correcting mistakes in the code so that now it does behave as documented. That's what patch releases do.
reply