Unusability of bluetooth is one of the worst plagues in Ubuntu

[Matteo Sisti Sette]

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.