First, thank you for your reply and thank you for taking my issue seriously.
Your reply makes me very hopeful. >quequotion [2012-09-05 19:34 -0000]: >> I'm actually happier with "Won't Fix" than "Invalid". >*shrug* fine for me :-) Changed. Because it more accurately explains why no action will be taken. "Won't Fix" implies that an issue may exist, but solving it directly doesn't fit with design plans. >> ie. "Report the problem for statistics" and "Report the problem on >> Launchpad" to distinguish the two completely different meanings of this >> phrase. >Correct. This pretty much reflects the two different modes that the >development vs. the stable releases are in. I don't think users of either are aware of this. I only noticed the inconsistency since upgrading to 12.04, but I tend to upgrade to every new release. (I am considering sticking with the LTS this time however.) >> but can provide instructions on how to prepare the system to file a >> valid report and how to restart from this point later, and also that >> the user can be shown search results from launchpad about possibly >> relevant bugs based on information collected so far if they like. >But Apport doesn't knwo what to do there. If you use a third-party >package, and that crashes, then that same crash may or may not affect >the Ubuntu package as well. Also, you probably use the third-party >package for some reason, so telling the user "uninstall that/go back >to the Ubuntu version" would not be particularly helpful and realistic >in my opinion? Maybe and maybe not. Some users, myself included, may have upgraded to ppa packages or use downloaded packages on a whim or ill-advice from some blog promoting the new features of a package that isn't in the repositories. Apport's advice doesn't have to be intelligent. It would be acceptable to me even if it told me to downgrade packages I had intentionally upgraded, whether or not I chose to follow that advice. More important is that apport could produce search results approximating the issue a user is having, which might yield a workaround or at the very least a similar report to follow. >Also, we did all this to avoid having to send users of stable releases >to Launchpad. That's a developer tool, requires an account, and is not >quite the thing that we want to inflict on users. I have an idea for this, and I doubt that I'm the first to come up with it. Short-term support releases could ask or require users to create a launchpad account during installation, in ubiquity. Particularly in STS releases, though I recommend it for LTS as well, a setting panel could be added to gnome-control-center for launchpad-integration that includes facility to associate a launchpad id with the user's installation. Later on, if those users upgrade to an LTS release, they will already have a launchpad account integrated with their distribution to participate in the bug resolution process. I find it far more reassuring that launchpad exists, and that I can participate in this process, as a user, than simply trusting that the developers received my data and may (or may not) solve the problem someday--which was exactly how "Error Reporting Service" in Windows XP worked. I never trusted that Microsoft read a single report sent by their service, not only because none of the errors were ever fixed, but because it never produced any feedback--it sent the wrong message by sending no message at all, and it lost my patronage. >> 4C. If apport finds no restricting conditions or previous reports of >> exactly this bug, apport will ask the user if they'd like to create a >> new bug report. >> >> 5. If the user would like to create a new bug report, then apport will >> take them to launchpad to go through the steps. >That's again what we deliberately do not want to do in stable >releases (the "won't fix" part). >We _will_ not fix every crash in stable releases, for both resource >and stability reasons. Asking users to spend a lot of time with >setting up accounts, filing bug reports, etc. it just wasted time and >creates false expectancies. I understand there aren't enough people or hours in the day to fix every problem, but isn't the point of LTS to maintain and improve stability, so long as it doesn't require new functionality? Of course not every user wants to fumble with launchpad, but there are ways to handle bugs reports that can prevent false expectancies and that is probably much better than rejection in the long run. >> If it's just sending statisticsto a database, and not telling me, >> without at least showing me an active bug report relevant to my >> issue, how am I supposed to belive that the problem will ever be >> solved? >This part is already in the works. I. e. if we have a fix for a >problem that affects you, you will get a notification that you need to >upgrade to this package version X.Y to correct it (and a button to do >that). It will most likely not land in 12.10 yet, but 13.04 seems >realistic. I am happy to hear this. This will mostly resolve the original problem I reported. >> Ubuntu needs to send the message that bugs will be handled with good >> communication and accessible developers - two things that open source >> software can uniquely provide. >Right, but that only scales up that much -- we can handle a couple of >thousand users on the development release, but not millions of >requests from stable release users. Of course there are limits to any resource--particularly human resources. I think improvements could be made to both launchpad and apport to reduce the number of new bug reports coming in. There are a lot of duplicate reports out there, and incomplete or mis-informed reports aplenty. Both apport and launchpad could require more thorough reports and scrutinize their content further to reduce those problems. Key points: -send users with vague, incomplete, or invalid reports to the forums to create a thread requesting help, to include all non-personal data collected so far, and show them possibly related issues in launchpad as well. (to take pressure off developers and lead people to solving their own problems or finding support from the community). -require relevant logs to file a new bug, providing instructions on how to collect them for new users -require users to read through similar bug reports and confirm that they are not the same issue before allowing a new bug report (not just list them for optional reading). -improve the "mark as duplicate" system, allowing confirmation or denial by the original reporter and merging the content of confirmed duplicates into a master report. >> I understand that not every developer can be called to account for >> every issue in every software package available for linux, but >> apport could go a long way toward making the face of linux "customer >> service" look better. >It's all a matter of putting scarce resources to their best use. >Spending 24/7 on triaging millions of Launchpad bugs and doing nothing >else will not help anyone :-) Agreed. Hopefully, the future will see linux--and Ubuntu in particular--becoming more popular. As that happens, I hope that Launchpad will be able to scale with increasing developer and user bases. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1036965 Title: Apport reports to errors.ubuntu.com, not Launchpad bugs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1036965/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
