papercutters team mailing list archive

[matteo sisti sette <1049082@xxxxxxxxxxxxxxxxxx>]

I am just a user, the only thing I can do is contribute my own humble
list of bugs I know of that are so critical that (a) It's beyond me that
they haven't got enough attention yet and (b) I don't even see the point
in having new major releases of ubuntu without having them fixed. Which
only makes sense if it is joined with lists provided by other users, of
course.

May I suggest to PLEASE forget the "bug has the 'confirmed' status" criteria when selecting important bugs to take action on!? 
Now that you mention it, that mostly explains how some tremendously critical bugs have remained unfixed across several major releases (which is really frustrating and disappointing). There are kinds of bugs that shouldn't require any confirmation whatsoever to be looked at, or that should be picked by developers (or anybody with the skills to do that) for the very purpose of checking whether they can reproduce them, and hence confirm them.

Consider crashes. If somebody reports a crash of, e.g., xorg, that should be enough to take that bug report seriously and investigate whether there is enough information in it to take some action. If you're going to wait for someone to confirm that, you're almost certainly going to wait forever. Unless you think users may actually be inventing bugs, or thinking a program has crashed when it hasn't. And a bug report generated by ubuntu-bug should contain enough information to discard that hypothesis.
Xorg is just an example, of course. When something as basic as xorg, ntfs.whatever, network-manager and the like, crashes, even if one single person has reported one single crash, it should be enough to trigger developers' attention to it to do whatever can be done to figure out what caused the crash. The only case when a bug report should be "forgotten" until new information is available, is if some developer has actually checked that there's not enough information to do anything about it. Where  "anything" does not necessarily mean "start working at fixing it" but also "try to figure out what _may_ reproduce it", etc.
The most disastrous crashes of the most vital components of the OS are usually hardly reproducible, so if you wait for confirmation or for a set of steps to reproduce the issue, you're going to leave the most critical bugs unsolved, exactly those that most need to be fixed.
Basically, crashes should be treated as confirmed by default (that would mean e.g. encouraging people to confirm their own bug reports if they are crashes, or even have some bot confirm bugs when they contain the word "crash/crashes").


Another thing that frustrates me beyond telling is when I report some critical bug, then I get an automated response that tells me to test the upstream kernel, and the bug report is put into the "incomplete" status, and then it expires. I never going to test the upstream, period. Does that mean that I shouldn't report the bug? Oh well, then you're never going to discover the bugs that "real users" face (where by "real users" I mean any people outside the cyrcle of those actively developing parts of Ubuntu).
That the particular person who reported a bug cannot or is not willing to do additional testing, is not a reason to have a bug expire. That makes me feel like I'm totally wasting my time when I report bugs. 
The very idea of bugs expiring is fundamentally wrong. A bug should be closed only when there is nothing left to be done about it. That means, when it is either fixed, or found to be a duplicate, or found to be invalid. If it is incomplete, then there IS something to be done about it: complete it. Just like a confirmed bug is considered ready to be picked by anybody capable of fixing it, an incomplete bug should be considered ready to be picked by anybody capable of doing the extra needed debugging/testing/figuring-out work so that it can be confirmed and/or triaged. Having a bug expire because it has been in the "incomplete" status for too long is exactly as wrong as it would be to have a bug expire because it hasn't been fixed for too long.

-- 
You received this bug notification because you are a member of
Papercutters, which is a bug assignee.
https://bugs.launchpad.net/bugs/1049082

Title:
  The "hundredpapercuts" project will make the Ubuntu experience to
  glaze

Status in One Hundred Papercuts:
  In Progress

Bug description:
  The Ubuntu experience is limited by plenty of small bugs. We are
  redesigning the "hundredpapercuts" project to make Ubuntu delightful
  by reducing them.

  This time we're trying the other way:
  - Instead of planning so hardly, working.
  - Instead of creating an impressive infrastructure, to create an agile one.
  - Instead of working in many aspect, to polish the very important things.
  - Instead of marketing the project; to make it recognizable, and to properly tie it.
  - Instead of setting great goals; to set a great mission, and to define goals for sure we will get.

  If you want this kind of bugs, as us, to be fixed; you may want to
  subscribe to this report and give your points of view in it. Although
  we will rather be working than commenting, we will carefully look at
  them.

  Thank you ♡

To manage notifications about this bug go to:
https://bugs.launchpad.net/hundredpapercuts/+bug/1049082/+subscriptions