Unusability of bluetooth is one of the worst plagues in Ubuntu

Sat Dec 28 14:38:58 UTC 2013

Sounds good.

Gabor Toth

Sent from Nexus 7
On Dec 28, 2013 2:50 PM, "Phill Whiteside" <PhillW at phillw.net> wrote:

> Hi,
>
> hugging a bug is one of the best things a non-programmer can do. Find a
> bug that you care about and see as an issue for the wider family and 'run
> with it'. Go and ask people about how much work is needed to solve it,
> research the bug to see if it is fixed in other members of the linux
> familiy (an example being that there was a patch for a bug in red-hat
> kernel which could then be pulled into the ubuntu one, via debian)...
> Sounds crazy? yes it is. It also takes a quite a lot of patience and time
> to follow things up. If you can give the people who *can* fix the bugs
> enough information they will happily assist you. There is a recent example
> that I 'ran' with and still owe a massive thanks to everyone else who
> provided information / patches / testing. Do read the bug history [1]
> entirely and you will get a good idea as to how involved hugging a bug can
> become :) But, it is exceedingly rewarding.
>
> Regards,
>
> Phill.
> 1. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1227202
>
>
> On 28 December 2013 12:46, Gabor Toth <gabor.me at gmail.com> wrote:
>
>> There are a lot of truths in what you are saying.  There seems to be some
>> points that I have different thoughts about.
>> There are limited programmer resources and seems to be a good idea to
>> pre-work which can be done by none-programmers.
>> There are and probably always will be some big amount of bug reports and
>> some of them are critical, some important, some not so important and some
>> trivial.  Thus one needs to prioritize somehow.  During this of course
>> mistakes can be made.
>> One of the way to see how important a bug is to try to reproduce.  A bug
>> to be a bug does not necessary need to be reproducable.  However you can
>> have bugs that are just freak incidents - had some which never returned -
>> ever.  Also if the bug can be only produced on one computer then it can be
>> an isolated bug effecting a rare architecture or set of circumstances. In
>> this case the question will rise how important that bug is compare to one
>> that appears on every or at least a lot of different computers. Also raises
>> the question how to fix it if the programmer does not have that
>> architecture and thus can't reproduce, test.  Pretty hard to work with I
>> would think.
>>
>> These are my thoughts.
>>
>> Ml,
>>
>> Gabor Toth
>>
>> Sent from Nexus 7
>> On Dec 28, 2013 1:12 PM, "Matteo Sisti Sette" <matteosistisette at gmail.com>
>> wrote:
>>
>>> On 27/12/13 23:22, Gabor Toth wrote:
>>>
>>>> Hi Matteo,
>>>>
>>>> You see several points correctly as far as I can see.  There is a point
>>>> though that I think your point is missing reality.
>>>>
>>> > As you know Ubuntu is
>>> > for a big part a community project or at least community
>>> > of volunteers pitch in with quite some work including
>>> > the bug squad [...]
>>>
>>> I don't think I missed that point. I think I do know that.
>>> Of course if there was an enterprise with money and resources to spend
>>> into maintaining Ubuntu (oh wait, there _is_ one and it's called Canonical,
>>> but anyway I don't know how big its resources are and how relevant compared
>>> to the volunteer effort of the opensource comminity at large) more people
>>> could be working at it and more work could be done. (And yes, no
>>> questioning that big enterprises with enormous resources like MS and A***e
>>> do an astonishingly bad job in using those resources.)
>>> The fact is that a lot of people _are_ working at it and a lot of work
>>> _is_ being done, and sometimes I get the impression that much of this
>>> effort is simply not put in the right direction.
>>>
>>> On this very list I read bits of a conversation (I thing it was about
>>> the 100-Papercuts project or whatever it is called) in which a list of
>>> directions was being made about things to do in order to progress as
>>> quickly and/or effectively as possible.
>>> One of the suggested directions was to look for bugs filtered by certain
>>> criteria and one of the criteria was:
>>> - confirmed bugs
>>> That seems to me tremendously wrong.
>>>
>>> It looks to me like there are some underlying assumptions in the way
>>> bugs are managed, among others:
>>> 1 - people and groups of people who dedicate their organized effort in
>>> thorough testing (let's call them "pro testers", regardless of whether
>>> their effort is volunteer or paid) will find and report the most part of
>>> the most relevant bugs (meaning those with the greatest impact on end users)
>>> 2 - Bug reports filed by "end users" don't deserve any attention until
>>> they are confirmed by at least another user
>>> 3 - Bug reports filed by "end users" don't deserve working at them until
>>> they include all the information
>>> 4 - If it is detected that some information is missing in order for a
>>> bug to be "workable", it is completely the responsibility of the original
>>> reporter to provide this information; until he/she doesn't, the bug report
>>> doesn't deserve any attention.
>>>
>>> All of these assumption are wrong; the last one probably the wrongest.
>>>
>>> I'll anticipate an objection to the last assumption in my list: that I
>>> get it wrong and the actual assumption being made is: the original reporter
>>> is the only one who can provide that additional information, and if he/she
>>> doesn't, sorry but there's nothing that can be done about that bug report.
>>> Well in many, many cases, that is simply untrue. So, the policy of
>>> completely ignoring a bug that is in the "need info" state until the
>>> original reporter responds, and have it expire if she doesn't within a
>>> given time, is simply wrong.
>>>
>>> In my opinion, the very concept of a bug report expiring is wrong.
>>>
>>> Just in case you want some arguments to back the statement that the
>>> mentioned assumptions are wrong:
>>> 1 - wrong. A huge lot of big-impact bugs will elude testing and be found
>>> by end users. Note that I'm not questioning at all that this work done by
>>> the "pro testers" should be done, nor that it's being done in the best way
>>> possible; I'm just saying it can't be assumed that it alone will accomplish
>>> the greatest part of the goal, making the rest scarcely relevant.
>>> 2 - wrong. In many cases there's no need to wait for a second person to
>>> incur in the same bug. Unless you think the reporter is inventing a fake
>>> bug (which of course is possible) or getting something wrong (which is even
>>> probable) but that can usually be verified or discarded by simply reading
>>> the report, without any need to reproduce the issue.
>>> 3 - wrong. They need work to be done in order to gather the missing
>>> information. In most cases, the original reporter won't do that.
>>> 4 - I think I've already made my point about this one.
>>>
>>>
>>> Ah, and another one:
>>> 5 - Bugs can't be fixed or don't deserve to be worked at if they can't
>>> be easily reproduced.
>>> Wrong. Of course a bug that can't be easily reproduced is a zillion
>>> times more difficult to fix. But then, if it can't be reproduced with the
>>> information provided by the original reporter, work needs to be done to
>>> find a way to easily reproduce it. So the bug report does need attention.
>>>
>>
>
>
> --
> https://wiki.ubuntu.com/phillw
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20131228/fc0bb7ba/attachment.html>