Hi Rainer,
On 26.05.2014 20:13, Rainer Bielefeld wrote:
It's an essential that information should be consistent at any place for
Bugzilla.
+1
Here an overview concerning priority /severity of the issues listed in
the meta-issue;
! Critical major normal trivial ! Total
---!-----------------------------------------!------
P1 ! 1 . . . ! 1
P2 ! . . . 1 ! 1
P3 ! . 4 5 . ! 9
---!-----------------------------------------!------
Tot! 1 4 5 1 ! 11
Regressions are also an important consideration.
So my question is why Issue 114361 with severity "trivial" has been
considered by godlike decision (there is no reasoning, neither in Issue
124985 nor in Issue 114361) so serious that it has been added added to
the meta bug? With some minimum carefulness the severity would have been
rised to "major" or more, the dataloss keyword would have been added, so
that the decision will be comprehensible. I did that now in Issue 114361
A higher severity was very much warranted for this data loss. Data loss
sounds a bit like an abstract concept but in this case it was "I had a
perfectly fine presentation, saved it and some pics are gone!!!".
So the meta-issue helped to identify that this important issue was not
properly flagged and would have been overlooked if we had only used the
query as suggested. +1 for the meta-issue then.
Common known characteristics of unresolved Issue 124985 blocking Bug
reports you find in Report [1] (More than 3400). So the question is why
have 11 been picked as blocker for the meta issue, but more of 3400 not
[2]?
For the references [1], [2] or [3] in your mail I cannot find their
actual links, but I think I know what you mean. As said the meta-issue
is only intended as a publicly visible reminder and best-effort overview
what should eventually get into an eventual bugfix release if we decide
whether we'll need one. The meta-issue helps with this discussion. +1
for the meta-issue.
Whether they really should get into an eventual bugfix release would be
decided later by requesting the blocker flag.
I'd say good criteria for such issues are:
- regressions
- crashes
- data losses
* risk of new regressions
So even if a bug is only minor; if it is a regression, a fix is
available and low risk it should get into a bugfix release. Such a bug
would not be caught by a query for major issues, but IMHO they are great
candidates anyway.
Should we decide that our bugfix releases must only contain fixes for
bugs with major severity then this is fine as well. The bugs below this
level would be removed from nomination. I'd advise against ignoring such
fixes though.
With some minimum corrections for the criteria of possible Meta bug
blockers I can reduce the number by 90% [3]
[...]
Such systematic working is the only way for real progress.
This systematic work is very important indeed and I appreciate and have
the deepest respect for our QA volunteer who work on it.
If after some work we have valid data in the bug reports Meta Bugs
indeed can be useful to show up dependencies and relations what are not
simply visible in the bug reports.
For anything else queries like
<https://issues.apache.org/ooo/buglist.cgi?cmdtype=runnamed&list_id=149854&namedcmd=Potential411Blockers>
(shared with registered users) are much more powerful, especially in
projects with bigger community than AOO and much bug tracker activity
(20 reports per day, not only 2).
I'm logged in and have all the rights needed but I can't see that query.
On the other hand the meta-issue is visible to everyone without any
trouble...
Best regards,
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
