On Fri, Jun 21, 2013 at 11:09 AM, Sub Phil <phil40...@gmail.com> wrote: > Bug policy debate and so on.. > > Well, just sharing experience from as a past developper and notorious bug > fighter. > > There is no other point in creating a database of bugs and not treating > them, than to have an ultra-complicated list of known issues (so complex > that users report are duplicated) and frustrated reporters (and testers). > > "It is no a display of disrespect when a certain bug is not fixed." > Yes until you have a list of open bugs, which generated itself a list of > duplicates... > What matters is the evolution ratio closed / confirmed by release (e.g. > 3.4.1) and cumulated version (3.4.x). >
Metrics like this could be useful if we're measuring defects not defect reports. Unfortunately the duplicates, plus the "how do I?" and other non-defects that users enter , make this difficult to estimate. My impression is that close to half of the Bugzilla reports are invalid. We'd need to do a major clean up of Bugzilla before we even knew how many actual defects are there. > "I would like to add another one. I am a developer. When I spend time on > fixing bugs then I sometimes wish there where a big list of all open bugs > that are sorted according to importance. I would go down the list and grab > a bug from the top that lies in the area of my expertise (Impress, UI, > Slideshow, Sidebar). Without such a list I have to prioritize bugs by > myself. And if I do that then I use my own judgement of which bug is > important and which is not." > To the extent that rated priority is a motivation to volunteers, this is true. But we have all sorts of volunteers. I think some of them have enough stress in their real lives that they don't want to take "high priority" issues and world rather work on lower priority ones, where there is less urgency. Also, much of this depends on where we are in the release. Once we have completed regression testing we want to avoid introducing additional risk. So it is no longer "open season" for fixing just any defect. We need to weigh the risks involved. In many cases, for less serious bugs, we fix them in a later release, so they can undergo a full test pass. > This further illustrate the fact that in order to handle these list, one > has introduced techniques such as priority and vote for bug. > > My own experience shows, that all these are not good policy for bug > treatment, it's a dispair. > Prioritization is not despair. It is just acknowledging that changing the code after testing has completed is risky, and that we should only make changes now where absolutely necessary. Despair is what users feel when we don't show such precautions and see a last minute fix introduce a serious bug that is not caught before release. > Bug should be assigned in groups regarding a feature with final objective > in mind. > What do I mean by feature. > Take for instance in Calc, the pivot table function. > All bug regarding pivot table should be treated together, or most of them. > Why concentrating? > Because: > 1/ It takes time to fix a bug, because one needs to understand or > re-understand the implementation. > "- Fixing a bug usually takes a lot more time and effort than reporting one. > Also, often because test case scenario are not narrow enough - see my other > post. > > 2/ By taking all bugs related to a piece of source code, each time you > become more familliar and so more efficient. In a sense you proof reading > it several times, you get leverage on bug handling. > > 3/ By reviewing several related bugs, you reduce the risk or regression, as > you've been through it several times, each time with a deeper understanding. > This is a good practice to follow, before the main test pass completes. After than we intentionally aim to minimize the changes to the code. Otherwise we don't have a good sense of what the quality is we're release. Bugs are bad, but with testing we can at least have a degree of confidence that there are no defects above a certain severity level. If we make unrestrained changes after the test pass then our degree of confidence is reduced or eliminated. > "The other thing to note is that bug fixes are not risk-free. Studies > have shown that 25% of defects in code are side effects of changes". > FFmpeg is really a good example for regression, to a point I stopped > reporting (first you have to convince it's a bug, then it lays pending to a > wish to fix it and then you find older release which works...) > I know it can be frustrating as a tester to see defects you reported go unfixed in a release. I've been there. > 4/ Having fixed a bulk of related feature bugs, report the fix is > implemented to all different reporters. They will(hopefully if done in a > reasonable time, not like me who got a mail for a bug I posted 2 years > ago...) test "their" bug and by doing so improve the total quality control > and reduce regression risk. > > > > What do I mean by assigning by objective. > > Well, here is for me where the votes should take place, grouped by user, > tester and developer (might have different interests). > > Suppose, pivot table code is considered as a mess by developpers and ought > to be re-written by next release. There is no point in fixing pivot table > bug now. > > Suppose users consider that priority should be assigned in this order > 1. fix doc format issues > 2. fix grammar check issues > > It has to be respected and if there is a "critical" bug in another field, > well if it will wait. > All good ideas. But we do need to respect where we are in the release cycle for AOO 4.0. Main testing is done. Main bug fixing is done. We're not going back to do feature work, clean up or whatever for this release. We're fixing a few remaining severe issues in preparation for release. The time to suggest specific other bugs for this release was many months ago. Of course, this is a great time to suggest specific bugs for AOO 4.1. Along with feature work for AOO 4.1 it would be great if we could identify priority bugs to fix in that release, so fixes could be integrated into the release before the AOO 4.1 test passes conclude. IMHO there are no bad ideas here. They are just mistimed ;-) Regards, -Rob > One should not vote for a bug, but rather for an expected behaviour. > > Phil > > 2013/6/21 Andre Fischer <awf....@gmail.com> > >> On 21.06.2013 13:42, Edwin Sharp wrote: >> >>> Dear Andre >>> This is exactly the problem! >>> When you grab a bug from the top and critical bugs continuously enter the >>> list - >>> The minor bugs at the bottom will never get attention. >>> >> You make that sound like it where a bad thing. >> A bug is critical because it affects man users and/or causes data loss >> (and one or the other additional property). Therefore it should be fixed >> before minor bugs are fixed. >> This is how it should work. If it does not then I see two reasons for it: >> >> - There is not one single sorted list of bugs. Everybody has his or her >> own idea of which bug is important and which isn't. >> >> - The way in which bugs are ordered is not good enough. This ordering is >> certainly not easy to define and it will be impossible to define it in a >> way that makes everybody happy. But if there where one central list of >> ordered bugs then we could at least try. And everybody could help to >> improve it. With such a list you have to rely on my judgement or that of >> other developers. >> >> -Andre >> >> >>> On Fri, Jun 21, 2013, at 14:24, Andre Fischer wrote: >>> >>>> >>>> All good ideas. >>>> >>>> I would like to add another one. I am a developer. When I spend time >>>> on fixing bugs then I sometimes wish there where a big list of all open >>>> bugs that are sorted according to importance. I would go down the list >>>> and grab a bug from the top that lies in the area of my expertise >>>> (Impress, UI, Slideshow, Sidebar). Without such a list I have to >>>> prioritize bugs by myself. And if I do that then I use my own judgement >>>> of which bug is important and which is not. >>>> >>>> Regards, >>>> Andre >>>> >>>> >>>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: >>> qa-unsubscribe@openoffice.**apache.org<qa-unsubscr...@openoffice.apache.org> >>> For additional commands, e-mail: qa-h...@openoffice.apache.org >>> >>> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> qa-unsubscribe@openoffice.**apache.org<qa-unsubscr...@openoffice.apache.org> >> For additional commands, e-mail: qa-h...@openoffice.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
