I've mostly given up on making Ubuntu bug reports(utcc.utoronto.ca)
utcc.utoronto.ca
I've mostly given up on making Ubuntu bug reports
https://utcc.utoronto.ca/~cks/space/blog/linux/UbuntuBugReportsUseless
80 comments
You happen to have a link at hand? I'm curious
Hmm, lets see... Yes, I found it: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1...
Comparing your comment here and what exactly went down in the bug report, it looks like you interpreted things the wrong way. Your comment reads like you were dealing with Canonical employees. However, looking at their profiles we can see that they are volunteers. I would also note that Paul's comment is not "implicitly chastising", but completely ordinary incremental triaging.
These types of interpretations are actually quite common in FOSS project bug trackers. A few months ago in LibreOffice's bug tracker some hostile person demanded that I be fired from Canonical (I have never worked for any company on LibreOffice).
These types of interpretations are actually quite common in FOSS project bug trackers. A few months ago in LibreOffice's bug tracker some hostile person demanded that I be fired from Canonical (I have never worked for any company on LibreOffice).
Fair enough, I didn't realize that these persons were volunteers and not employees. That, uh, changes things.
To be clear, I wasn't suggesting anyone at Canonical should be fired. If anything, the opposite so they would have more resources to deal with bug reports.
To be clear, I wasn't suggesting anyone at Canonical should be fired. If anything, the opposite so they would have more resources to deal with bug reports.
> However, in June 2018 I answered a call from the Canonical Desktop Team to look at old untouched Firefox bugs with the aim of removing at least 250 of them from Launchpad after verifying that they were no longer valid. I am currently, as at August 2018, also looking at other packages and I estimate that I will remove in excess of 1000 bug reports from Launchpad relating to the following applications:
That might explains some thing.
That might explains some thing.
I made a thing that ubuntu now (recently) includes in their distro. Canonical employees have filed tickets with me about this thing. Responses to it, by me, are generally ignored for many weeks/months. They've patched the thing in weird ways without contributing anything back (upstream as it were).
This does not seem like 1) a good model for floss developers to give a shit about Canonical, 2) a good model for Canonical to support (non-corporate?) users
This does not seem like 1) a good model for floss developers to give a shit about Canonical, 2) a good model for Canonical to support (non-corporate?) users
Hey craftyguy. I assume you are talking about networkd-dispatcher?
I understand if you feel like your responses are being ignored. I was focused on other things the past weeks, I'd love to be more responsive.
WRT patching things in weird ways and not contributing back, I don't understand it.
We are shipping three patches in Ubuntu:
(1) Changing from Arch's /etc/conf.d to the Debian/Ubuntu /etc/default directory.
(2) Switch form /etc/networkd-dispatcher to /usr/lib/networkd-dispatcher.
(3) Running with --run-startup-triggers by default.
(1) and (3) are distro-specific things. Sure (1) could be made an option somewhere or something, but that sounds more complicated than just fixing the path to match the policy.
For (2), I opened a bug about supporting both directories. The most important part for us was having the ability to package our hooks in /usr for the 18.04 release, though, so I had to quickly patch that in. I fully intend to support both paths and then send you a pull request, but I think it's clear that a pull request at the current time would not be worthwhile.
I hope that this addresses your concerns.
I understand if you feel like your responses are being ignored. I was focused on other things the past weeks, I'd love to be more responsive.
WRT patching things in weird ways and not contributing back, I don't understand it.
We are shipping three patches in Ubuntu:
(1) Changing from Arch's /etc/conf.d to the Debian/Ubuntu /etc/default directory.
(2) Switch form /etc/networkd-dispatcher to /usr/lib/networkd-dispatcher.
(3) Running with --run-startup-triggers by default.
(1) and (3) are distro-specific things. Sure (1) could be made an option somewhere or something, but that sounds more complicated than just fixing the path to match the policy.
For (2), I opened a bug about supporting both directories. The most important part for us was having the ability to package our hooks in /usr for the 18.04 release, though, so I had to quickly patch that in. I fully intend to support both paths and then send you a pull request, but I think it's clear that a pull request at the current time would not be worthwhile.
I hope that this addresses your concerns.
You aren't secretly JWZ are you? hah Seems to be a pattern of behavior.
They've patched the thing in weird ways without contributing anything back (upstream as it were).
I've had this problem with both Debian and Ubuntu. Sometimes the patches they apply are good, sometimes bad; but I wish they at least had a social norm of "contact the upstream project and offer them the patches". It's annoying when the first I hear about a patch is when a user contacts me to complain that something is broken.
I've had this problem with both Debian and Ubuntu. Sometimes the patches they apply are good, sometimes bad; but I wish they at least had a social norm of "contact the upstream project and offer them the patches". It's annoying when the first I hear about a patch is when a user contacts me to complain that something is broken.
For Debian - would you say that's mostly package owner dependent, or more tied to the policy of "bug-fix without api change only" in stable? Or just overall poor culture of communicating with upstream - when upstream != maintainer of Debian package?
None of the cases I've seen have been related to the policy of avoiding API changes in stable. Most of them seem to be instances of "user files a bug with Debian; package maintainer adds a patch to address user's complaint but doesn't relay the bug report or the patch upstream".
> 2) a good model for Canonical to support (non-corporate?) users
What on Earth made you think Canonical cares about supporting non-corporate users :-)?
What on Earth made you think Canonical cares about supporting non-corporate users :-)?
Probably an unpopular opinion, but when a project is starving financially, responding to bug reports should be the first thing to go. Hugely popular features and large subprojects
that change the direction of the project are more important than the average bug fix. One of my projects has 1000 new open issues in the last year, and I'm the only paid contributer, so the chance your issue will even be responded to is about 25%. Only the highest quality bug reports are addressed. If not enough information is provided, you can pretty much guarantee it will be ignored because there are hundreds of other issues that are written better and deserve better attention.
Without knowing anything about the blogger's bug reports, I'm going to guess this is what's happening at Canonical that is causing bug reports to not be addressed.
Without knowing anything about the blogger's bug reports, I'm going to guess this is what's happening at Canonical that is causing bug reports to not be addressed.
The blogger's bug report he linked to was about a package in universe. Universe is essentially the community playing ground - packages there are not supported, and most of them are synced unmodified from Debian and not there because anybody cares about them.
The best course of action with universe packages thus is to fix them yourselves. Ubuntu development is open to everyone. All you need to do is submit a debdiff and subscribe the ubuntu-sponsors team. You can even submit stable release updates with sponsoring, https://wiki.ubuntu.com/StableReleaseUpdates tells you more.
If you can't do the development yourself, and there's no community member who cares about the package, your bug might not get fixed. But that's the way things work in free software communities.
The best course of action with universe packages thus is to fix them yourselves. Ubuntu development is open to everyone. All you need to do is submit a debdiff and subscribe the ubuntu-sponsors team. You can even submit stable release updates with sponsoring, https://wiki.ubuntu.com/StableReleaseUpdates tells you more.
If you can't do the development yourself, and there's no community member who cares about the package, your bug might not get fixed. But that's the way things work in free software communities.
This is a good way to increase your churn. If your product has known bugs affecting my workflow that I have reported and you have not even responded to (a valid response could include instructions for preparing a patch/PR or even a message saying needs more info) I will always be looking for alternatives. If you are adding pointless features (to me as a user I started using the product with the existing feature set so new features are most likely pointless to me) at the same time I'm really starting to wonder about just forking.
For Ubuntu, you're probably right. For a year-old immature project like mine, it's definitely better to work on steering the cruise ship itself rather than work on tiny problems on it. Every project has its own rules, so make judgements on a case-by-case basis. But I'm not here to discuss my project, simply a guess as to the reason Canonical has disappointed the blogger.
My usual rule of thumb (with no particular evidence) is that for every bug that's reported, another 9 users are having the same problem.
That said, what you prioritize depends on what you want out of the project, be that features at all costs, or building a small but sustainable community of users for the long term. It's a perfectly valid thing to throw code over the wall and tell people to fix their own bugs, but don't expect to build a solid community around it.
That said, what you prioritize depends on what you want out of the project, be that features at all costs, or building a small but sustainable community of users for the long term. It's a perfectly valid thing to throw code over the wall and tell people to fix their own bugs, but don't expect to build a solid community around it.
Sounds about right. For me it's probably closer to 20-30 users.
With my commercial projects I've always had a policy of no known bugs. If I wasn't able to handle this then I'd consider it a warning that the scope of the project was too large.
And this is how to retain users. Although you might struggle to sell support contracts with preferential access to bug fixes...
I'm interested in how this works. Obviously there are bugs which can and should be fixed - but how about bugs which are really feature requests, or bugs which are extremely complex to fix and only affect 1 person? Do you mean that you close out these bugs very quickly without fixing them, or do you take superhuman efforts to implement everything?
Bugs can be triaged into deficiencies and new feature requests. Usually new feature requests are handled differently than actual bugs. For hard-to-fix bugs that don’t affect many people, sometimes documenting it as a known issue along with a workaround is good enough.
I don't worry if it only affects one person, I assume there are more that haven't told me or haven't found it yet.
I also don't worry if it's complex, I have had seemingly simple requests take several weeks although that is quite rare. I have never closed a bug as won't fix.
I also don't worry if it's complex, I have had seemingly simple requests take several weeks although that is quite rare. I have never closed a bug as won't fix.
Probably an unpopular opinion, but when a project is starving financially, responding to bug reports should be the first thing to go.
Or effort could go into trying to improve the funding situation.
Or effort could go into trying to improve the funding situation.
No just realistic. MS can afford patch Tuesday.
Then close the bug tracker, don’t waste everyone’s time. The serious bugs will pop up in some ways.
I’ve filed proper bug reports that went nowhere and guess what, I’ve lost interest in doing so since it was pointless. I’ve moved on to other projects that took them more seriously.
I’ve filed proper bug reports that went nowhere and guess what, I’ve lost interest in doing so since it was pointless. I’ve moved on to other projects that took them more seriously.
Contrary to what the post says, I usually have the same experience filing bug reports on Debian: most of the time no one replies. However, even though I no longer really expect anyone to react, I still think it's useful to report bugs. Indeed, when I have a problem and am searching for explanations, it's often very useful to find a bug report even if the bug has not been fixed: it can help you confirm that the problem is not specific to your setup, can give you hints about what is causing it, can suggest possible workarounds, etc. So even "giving up" on Ubuntu bug reports doesn't mean it's not useful to report bugs, IMHO.
I agree. Even if ignored by the distro, I've had other users do a better job than I could tracking down the source of bug reports I've posted and either offering work arounds or what new upstream release is likely to fix it.
And I manage to help out on some others too occasionally. Even if you're just creating a record of the specific error message for other users to search for and collect their experiences of it in one place - that still has some value to the community.
I have had reasonable luck with some portion of Ubuntu bug reports though - especially from the Samba/Winbind maintainers over the years. They did have their work cut out for them :)
If an Ubuntu package is part of Universe instead of Main, it's tough going getting Canonical to care much about it though. Universe packages basically just come down from Debian, while the Main packages are created and maintained by Ubuntu.
And I manage to help out on some others too occasionally. Even if you're just creating a record of the specific error message for other users to search for and collect their experiences of it in one place - that still has some value to the community.
I have had reasonable luck with some portion of Ubuntu bug reports though - especially from the Samba/Winbind maintainers over the years. They did have their work cut out for them :)
If an Ubuntu package is part of Universe instead of Main, it's tough going getting Canonical to care much about it though. Universe packages basically just come down from Debian, while the Main packages are created and maintained by Ubuntu.
I've reported an Xorg crash almost a year ago. Nobody looked into it. This was on a work laptop and it rendered it unusable for work because X would crash several times a day. I managed to work around it by downgrading X, but I recently got a new Thunderbolt dock which doesn't work too well on 16.04 but works well on 18.04, however on 18.04 I don't have the option of installing the version of X that doesn't crash multiple times a day.
This makes me very sad because I've had to go through quite a bit of trouble to be able to use Ubuntu on my work laptop in an org where Windows is standard. This makes me understand why the IT department is unwilling to support Ubuntu.
This makes me very sad because I've had to go through quite a bit of trouble to be able to use Ubuntu on my work laptop in an org where Windows is standard. This makes me understand why the IT department is unwilling to support Ubuntu.
It's not just Ubuntu, and it's not just open source. I've adopted a policy of filing no more bug reports on anything, free or commercial. All it's ever resulted in is arguments from developers about why they're not going to fix the bug. It's a waste of everyone's time. (Of course I think it would be a good use of time to fix the bug – but if you're not going to do that, then arguing about it is a useless distraction; everyone would be better off if I didn't file the report in the first place.)
Not every crowd is like that. If you ever use DB Browser for SQLite (sqlitebrowser.org) and hit a bug, please report it.
We have a bunch of open bug reports already, but we do get a reasonable number of reported things fixed and it's continually ongoing.
Also, but reports often turn out to have a workaround we know of and can suggest in the meantime. :)
We have a bunch of open bug reports already, but we do get a reasonable number of reported things fixed and it's continually ongoing.
Also, but reports often turn out to have a workaround we know of and can suggest in the meantime. :)
On the other end of the spectrum I get occasional updates for a Libre Office bug I filed years ago. They were very open, welcoming, and conscientious.
Nice to hear, I am a volunteer in the LibreOffice QA team.
We do automated calls for re-testing for reports in NEW state (=triaged) that have been untouched for a year. Earlier experiments with thorough re-testing always resulted in 20-25% of the tested reports being closed as WORKSFORME (so either duplicates of fixed issues or otherwise "silently fixed").
Our QA engineer has developed a set of scripts that help him make sure the bug tracker is not a mess: https://gerrit.libreoffice.org/gitweb?p=dev-tools.git;a=tree... https://wiki.documentfoundation.org/QA/Bugzilla/AutomatedTas... Much of this was inspired by our "gardening" effort: https://wiki.documentfoundation.org/QA/Bugzilla/Gardening
Deeper re-triaging of old reports also happens constantly. A couple of months ago I did a bisecting run for about a hundred older and newer bugs.
On the topic: I hope Ubuntu users continue reporting bugs. Upstream projects do benefit from them, I know this for a fact from our own experience.
We do automated calls for re-testing for reports in NEW state (=triaged) that have been untouched for a year. Earlier experiments with thorough re-testing always resulted in 20-25% of the tested reports being closed as WORKSFORME (so either duplicates of fixed issues or otherwise "silently fixed").
Our QA engineer has developed a set of scripts that help him make sure the bug tracker is not a mess: https://gerrit.libreoffice.org/gitweb?p=dev-tools.git;a=tree... https://wiki.documentfoundation.org/QA/Bugzilla/AutomatedTas... Much of this was inspired by our "gardening" effort: https://wiki.documentfoundation.org/QA/Bugzilla/Gardening
Deeper re-triaging of old reports also happens constantly. A couple of months ago I did a bisecting run for about a hundred older and newer bugs.
On the topic: I hope Ubuntu users continue reporting bugs. Upstream projects do benefit from them, I know this for a fact from our own experience.
Mind sharing? Curious to see. At least as a model for myself.
Not OP but I filed this Launchpad bug and the package developer responded the same day, even explaining how to recover data that had gone missing: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/12602...
This may be the exception to the rule but I was really impressed.
This may be the exception to the rule but I was really impressed.
Canonical has about 500 employees, Red Hat about 12,000.
It takes a certain scale to herd all the open source cats
It takes a certain scale to herd all the open source cats
This doesn't excuse many of the other things they do, like (often badly) patching upstream code and not sending the patches upstream.
It's one thing when you simply don't have the resources or the manpower to respond to all the bugs. That's understandable -- you deal with the really important ones and oh well.
It's totally another thing when even the ones you deal with, you deal with poorly. Especially when, more often than not, upstreams tend to be helpful, especially with large distributions like Ubuntu. A bad patch can always be made better. No communication leaves things exactly as they were. A bad patch and no communication makes them even worse.
It's one thing when you simply don't have the resources or the manpower to respond to all the bugs. That's understandable -- you deal with the really important ones and oh well.
It's totally another thing when even the ones you deal with, you deal with poorly. Especially when, more often than not, upstreams tend to be helpful, especially with large distributions like Ubuntu. A bad patch can always be made better. No communication leaves things exactly as they were. A bad patch and no communication makes them even worse.
Also, since Ubuntu aims at regular users, the quality of their bug reports is probably also lower on average than some other distributions.
The few times I bumped into an Ubuntu bug report, it was typically very long, light on useful data points for debugging/reproducing, and had several unrelated bugs in the same comments.
The few times I bumped into an Ubuntu bug report, it was typically very long, light on useful data points for debugging/reproducing, and had several unrelated bugs in the same comments.
The scope of Ubuntu’s bug tracker is vast. They accept bug reports against any package. I guess users will see packages as part of one integrated whole that Ubuntu is taking responsibility for. But I do wonder if there is a better way of Canonical delegating some of these bug reports to upstream.
I've rarely ever had Ubuntu bug reports be useful (and I follow up with more info when I'm asked) but can I really be annoyed? It's an open source product. I'm a software engineer. When it's important enjoy, I'll fix it. About the only useful thing is that other people also discuss it there.
Launchpad is useful as a single interface and Ubuntu-bug reports lots of info automatically so that's why I report there. Maybe I should use upstream.
Launchpad is useful as a single interface and Ubuntu-bug reports lots of info automatically so that's why I report there. Maybe I should use upstream.
In my experience its really bad for your mental health to read the source code of software you use, there is a troubling amount of horrific code in widespread use.
Great that you can cover everything from security to networking in a multimillion LOC project. I guess this is not a average software engineer skillset.
Outside of certain areas - if you manage to reliably reproduce the bug, you're likely to able understand the bug, and it's likely you can fix it.
But sure, there are areas where things can go very wrong. Prime example being the horrible Debian ssh/ssl key gen entropy bug:
https://lists.debian.org/debian-security-announce/2008/msg00...
(note that this was a "bug-fix" introduced after a misguided effort of looking for bad code - so a bit different from the typical "I triggered this bug in normal use").
But sure, there are areas where things can go very wrong. Prime example being the horrible Debian ssh/ssl key gen entropy bug:
https://lists.debian.org/debian-security-announce/2008/msg00...
(note that this was a "bug-fix" introduced after a misguided effort of looking for bad code - so a bit different from the typical "I triggered this bug in normal use").
I took your comment to mean that we shouldn't demand the time of volunteer open-source developers. I agree. But Canonical is a for-profit company.
Unless you are paying them, yourself, can you really expect more from them than from a volunteer developer? Maybe they're quite responsive to their enterprise customers. I, personally, suspect they are. On average that may lead to at least some trickle down gains for non-enterprise users, even if their specific reports are useless and pointless.
Fair enough, although I would expect some sort of loss-leader level of support that isn't entirely useless, if you are to drive enterprise adoption from the bottom-up.
Five years ago I submitted a fair amount of bug reports. A lot of them were merged into similar bugs and eventually fixed. The rest were dismissed as not corroborated, and honestly I found another fix, which was usually like undoing something I had customized poorly.
I haven't in some time, but that's only because I haven't been hit by many bugs that I can think of.
My 16.04 -> 18.04 upgrades suffered on three machines from a thing where I had to keep just running apt upgrade several times. I think this is related to why 18.04.1 was delayed, but whatever, it mostly seemed related to third party packages and development headers the common user probably never has.
I haven't in some time, but that's only because I haven't been hit by many bugs that I can think of.
My 16.04 -> 18.04 upgrades suffered on three machines from a thing where I had to keep just running apt upgrade several times. I think this is related to why 18.04.1 was delayed, but whatever, it mostly seemed related to third party packages and development headers the common user probably never has.
I recently tried to install Ubuntu on somewhat recent hardware and it was a complete trainwreck. I'm talking about installer broken right off the bat that required multiple grub hacks to fix. It then proceeded to install a completely broken system.
The only thing that worked (kind of) was recovery mode with command line only, and even that installed had a broken resolvconf (missing /etc/resolv.conf), so networking was working but DNS wasn't configured so couldn't resolve anything to actually do anything useful.
Numerous attention to detail/UI bugs in the installer irrespective of the problems that could have been specific to my hardware support lead me to believe quality and effort level have overall plummeted.
The experience harkened back to late 90's linux distro level of frustration. In short, it's a complete mess. Don't bother with Ubuntu, just let it die already.
The only thing that worked (kind of) was recovery mode with command line only, and even that installed had a broken resolvconf (missing /etc/resolv.conf), so networking was working but DNS wasn't configured so couldn't resolve anything to actually do anything useful.
Numerous attention to detail/UI bugs in the installer irrespective of the problems that could have been specific to my hardware support lead me to believe quality and effort level have overall plummeted.
The experience harkened back to late 90's linux distro level of frustration. In short, it's a complete mess. Don't bother with Ubuntu, just let it die already.
My response got too long; wrote a blog entry: https://l0b0.wordpress.com/2018/09/01/if-you-cant-support-yo...
I think it can be a problem of many Debian-based distributions, which are quite often supplying very old packages. RPM-based distributions are usually providing more updated software and perform updates more often. My personal favorites are Gentoo (for fun), Arch (for VMs) and Fedora (for work). They all are have an active and striving developers' community , except Gentoo which suffers from developers shortage. But if I fill a bug in existing package in these distributions, I am sure it will not be in vain.
Sure if you ignore CentoOS and RedHat.
The problem is that people that use Linux for work do not want o update the work machine daily, if there is no backup machine probably people like me will use an LTS for 3-5 years.
Since I use some older package and report a bug the upstream developers will most of the time ask to check the latest version and probably I can't have access to that package,
In case you would made the ar5gument that Arch is better and it never broke for you , even in a perfect world with no bugs you have the new features that roll out and that can break your workflow when useful things you used are removed or changed(if you use GNOME and you do not read on it's development I imagine how surprised people are when shit is removed or moved around every release)
Since I use some older package and report a bug the upstream developers will most of the time ask to check the latest version and probably I can't have access to that package,
In case you would made the ar5gument that Arch is better and it never broke for you , even in a perfect world with no bugs you have the new features that roll out and that can break your workflow when useful things you used are removed or changed(if you use GNOME and you do not read on it's development I imagine how surprised people are when shit is removed or moved around every release)
Rolling-release distributions (Gentoo, Arch) are very hard to use in a work environment. When it's the last day before release and I have two bugs to squash and eight hours for it, the last thing I want to do is babysit my computer through whatever broke at the last update.
Fedora is the same, except the breakage happens every six months. No thanks.
I'm happy to run these in a VM for development, or at home, but not at work, the place where I have absolutely zero intention of spending more than the fixed daily amount in my contract.
Fedora is the same, except the breakage happens every six months. No thanks.
I'm happy to run these in a VM for development, or at home, but not at work, the place where I have absolutely zero intention of spending more than the fixed daily amount in my contract.
I've never had any luck reporting bugs on fedora.
Throwback to JWZ writing in 2003 - https://www.jwz.org/doc/cadt.html
"[..] my bug reports to open source software projects [..] I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems"
"[..] my bug reports to open source software projects [..] I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems"
You've got absolutely a point. But, if you really use Ubuntu for making money, consider an Ubuntu Advantage subscription, that should let Canonical prioritize your tickets.
Oddly enough, as I'd never heard of that, I looked at it - it isn't for individuals. FYI, in case anyone else was interested.
Support for individual desktop users sounds interesting but I see big problems that makes this very expensive,
1 the hardware, this support program could work only for certified hardware and using certified drivers, no latest nvidia driver beta(I got kernel crashes because of video drivers both on Linux and Windows and the blame would be on the driver vendor)
2 Some users are stupid, if you ever did customer support you will know (in one case a person complained our application was missing a button, in the end I use TeamView to see the weird issue and guess what, the user dragged the window down so the button was offscreen, this is maybe a Window Manager but , it was on Windows or Mac I do not remember) my point is your customer support team will waste a lot of time so the support program can be expensive.
1 the hardware, this support program could work only for certified hardware and using certified drivers, no latest nvidia driver beta(I got kernel crashes because of video drivers both on Linux and Windows and the blame would be on the driver vendor)
2 Some users are stupid, if you ever did customer support you will know (in one case a person complained our application was missing a button, in the end I use TeamView to see the weird issue and guess what, the user dragged the window down so the button was offscreen, this is maybe a Window Manager but , it was on Windows or Mac I do not remember) my point is your customer support team will waste a lot of time so the support program can be expensive.
I paid Canonical for single-seat support for a while years ago. It was useless.
The main problem isn't either of the above. It's that there's no way the annual single-seat price can pay for the time of a competent person investigating even a single incident.
The economics have a chance of working out if an org with a large number of seats pays for support before they have a concrete problem and when they do, the the number of incidents they file don't scale with the number of seats.
The main problem isn't either of the above. It's that there's no way the annual single-seat price can pay for the time of a competent person investigating even a single incident.
The economics have a chance of working out if an org with a large number of seats pays for support before they have a concrete problem and when they do, the the number of incidents they file don't scale with the number of seats.
This wouldn't be an issue if support charged for the amount of time spent. If the user spends their money getting stupid non issues looked at then thats their issue.
Does this work? IS anybody using it?
I feel like people would complain it took say 20 developers hours to fix some trivial bug where in fact that specific bug was not that trivial to fix.
Then the situation is complicated since you don't control the upstream and if I fix a bug in upstream software X I may have to spend more hours convincing the maintainer that the fix should be included, sometimes the meinteiner has different ideas on how it should be done,
Now imagine the bug "There is no system ray anymore, I can't see my Slack,Skype,Dropbox icons there and I want them back. You can't fix this without forking GNOME and you get a new holly war with the GNOME camp (Canonical does not care about desktop anymore anyway this was just an example)
Then the situation is complicated since you don't control the upstream and if I fix a bug in upstream software X I may have to spend more hours convincing the maintainer that the fix should be included, sometimes the meinteiner has different ideas on how it should be done,
Now imagine the bug "There is no system ray anymore, I can't see my Slack,Skype,Dropbox icons there and I want them back. You can't fix this without forking GNOME and you get a new holly war with the GNOME camp (Canonical does not care about desktop anymore anyway this was just an example)
Funny how suddendly commercial software makes sense
Oh believe me, I think FOSS software is garbage in almost every case. There are a few shining counterexamples, but for the most part apparently paying people a living wage to do things makes for generally better stuff.
Who knew, right?
Who knew, right?
I think generally linux distribution bug reports aren't that important to most other types of software, since you can always do so much to diagnose and work around issues yourself. And if there is a bug in software I use like kdenlive or Gimp I'll go to the developers directly obviously.
Also most users are morons, it takes a lot of time to sort through all the invalid reports.
Also most users are morons, it takes a lot of time to sort through all the invalid reports.
Also a lot of the bugs will affect such a tiny percent like users with some obscure Bluetooth card trying to use some uncommon feature. Ubuntu could spend all year closing obscure bugs and almost none of their users would benefit.
[deleted]
Thought they have a long term support version?! And if not in real term other than name, can try what Apple do - from time to time has a no feature version.
They do, that's what LTS stands for. But "support" doesn't mean they'll look at your bug reports, it means they'll continue providing repositories and security patches.
Perhaps the best thing to do is to file the bugs against Debian. That way Ubuntu among the other derivatives will eventually silently upstream the fixes.
Does anyone who isn't a Ubuntu dev themselves get a good outcome from filing bugs on Launchpad?
Freeware at its finest
Proprietary software just wouldn't have a bug tracker for you to use.
Microsoft seems to be using UserVoice rather well.
They won't solve every issue posted to it though. Also microsoft does things differently to Linux distros. Hardware manufacturers have to make sure their devices work with windows and software devs have to do the same. Canonical accepts bug reports on just about any hardware and the thousands of programs in the repos.
Oh well, maybe someone else will fix it in another 6 years..