Unusability of bluetooth is one of the worst plagues in Ubuntu

[Gabor Toth]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20131228/1e11da47/attachment.html>