Sounds good. Gabor Toth
Sent from Nexus 7 On Dec 28, 2013 2:50 PM, "Phill Whiteside" <[email protected]> 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 <[email protected]> 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" <[email protected]> >> 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 >
-- Ubuntu-quality mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
