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.
--
Ubuntu-quality mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
