I filed a bug about an admittedly trivial issue about 6 years ago. Suddenly this summer there was a bunch of activity on it, somebody looked into it and made an effort to fix it. But that person was apparently new and didn't really know what to do, so I tried to handhold that person a bit. Then suddenly someone (that person's supervisor?) writes a comment implicitly chastising the person for spending time on a "low importance" bug. After that, the bug report went silent again.
Oh well, maybe someone else will fix it in another 6 years..
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
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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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.)
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").
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.
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 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.
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.
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 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.
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)
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.
"[..] 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.
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.
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.
[+] [-] jabl|7 years ago|reply
Oh well, maybe someone else will fix it in another 6 years..
[+] [-] bauerd|7 years ago|reply
[+] [-] craftyguy|7 years ago|reply
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
[+] [-] cperciva|7 years ago|reply
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.
[+] [-] julian-klode|7 years ago|reply
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.
[+] [-] jdhendrickson|7 years ago|reply
[+] [-] alxlaz|7 years ago|reply
What on Earth made you think Canonical cares about supporting non-corporate users :-)?
[+] [-] vortico|7 years ago|reply
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.
[+] [-] dbdjfjrjvebd|7 years ago|reply
[+] [-] rwmj|7 years ago|reply
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.
[+] [-] tonyedgecombe|7 years ago|reply
[+] [-] mikhailt|7 years ago|reply
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.
[+] [-] julian-klode|7 years ago|reply
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.
[+] [-] DoreenMichele|7 years ago|reply
Or effort could go into trying to improve the funding situation.
[+] [-] phobosdeimos|7 years ago|reply
[+] [-] a3_nm|7 years ago|reply
[+] [-] shock|7 years ago|reply
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.
[+] [-] rwallace|7 years ago|reply
[+] [-] justinclift|7 years ago|reply
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. :)
[+] [-] tomcam|7 years ago|reply
[+] [-] buovjaga|7 years ago|reply
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.
[+] [-] scarejunba|7 years ago|reply
[+] [-] pixelbeat__|7 years ago|reply
It takes a certain scale to herd all the open source cats
[+] [-] alxlaz|7 years ago|reply
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.
[+] [-] microtonal|7 years ago|reply
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.
[+] [-] jl6|7 years ago|reply
[+] [-] scarejunba|7 years ago|reply
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.
[+] [-] zorkw4rg|7 years ago|reply
[+] [-] StreamBright|7 years ago|reply
[+] [-] garmaine|7 years ago|reply
[+] [-] hugh4life|7 years ago|reply
[+] [-] hegz|7 years ago|reply
[+] [-] th0ma5|7 years ago|reply
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.
[+] [-] iamleppert|7 years ago|reply
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.
[+] [-] l0b0|7 years ago|reply
[+] [-] xvilka|7 years ago|reply
[+] [-] simion314|7 years ago|reply
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)
[+] [-] alxlaz|7 years ago|reply
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.
[+] [-] HeadsUpHigh|7 years ago|reply
[+] [-] jodrellblank|7 years ago|reply
"[..] 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"
[+] [-] alanfranzoni|7 years ago|reply
[+] [-] analognoise|7 years ago|reply
[+] [-] zorkw4rg|7 years ago|reply
Also most users are morons, it takes a lot of time to sort through all the invalid reports.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] ngcc_hk|7 years ago|reply
[+] [-] phyzome|7 years ago|reply