Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index

On 8/15/2012 3:20 PM, Marc Grober wrote:
On 8/15/12 1:57 PM, Andrew Brager wrote:
Thanks for your comments.  What still remains unclear to me (not that it
matters as I have no influence/authority on anything done by anyone  -
I'm simply trying to help you all sort it out so somebody in a position
to do something can then do it) is whether the bug status was changed in
that 5 month period between when you re-confirmed the bug, and when it
was closed.

In other words, did it get changed from NEEDINFO to NEW when you
reconfirmed the bug, as was implied should have happened?  Or did it go
from NEEDINFO to CLOSED with no intervening status?  If the latter, then
in my opinion there's a bug in bugzilla as (I would think) it should
have changed when you reconfirmed the bug.  If the former, then there's
a problem with the process, not the tool.  The answers to those
questions will answer the question "which one needs fixing?"  If the
process needs fixing, then in my opinion there needs to be additional
status flags and additional feedback from the developers as I previously

Based on Florien's post, it sounds like he only closed those that were
in the NEEDINFO state, which implies there's a bug in bugzilla as I
state above.
I think there is another possibility, and that is that the bug lifecycle
is dubious. See,

That diagram is in fact interesting. Based on that diagram (which may or may not be utilized by the LO team), then the process followed by the LO team is in error. They've chosen to dump unconfirmed bugs back on the user community, instead of confirming the bugs themselves. I can understand why they've done it, the work is probably overwhelming and they're volunteers so they've chosen to let each individual user/bug submitter either resubmit or assume resolved status. Not a bad choice from their point of view, it's the path of least work for them. It makes sense from that viewpoint. The proper way to do it would have been to check each bug themselves as normally would be done prior to a production release. They took the practical, expedient approach instead and I don't think you can fault them for doing so.

With respect to LO bugs,  it is still unclear what the various stages of
the bug lifecycle is, and who is empowered to make various changes to
the bug status. As an unempowered user I cannot "confirm" a bug.

Nor should you be able to confirm a bug. And that of course is where the model (or process) is broken, since as I mentioned above they've dumped the testing back on the user - with decent reasoning - but it still breaks the model as provided by the diagram. So yes, somebody on the developer's side needs to make some decisions as to how best to fix the model and/or process. Personally I don't see a problem with their decision to dump the bugs back on the user considering they themselves are volunteers, but somewhere somehow the status needs to change from NEEDINFO to NEW (which is not provided for in the model so clearly things have changed either with the model as supplied by bugzilla, or the LO team has customized their copy. So, I reiterate my previous comment that more info. is needed from the bug submitters as to what stages the status flags went through to determine whether it's the process or bugzilla that needs fixing.

Moreover, there is no context help available regarding status hierarchy.

What I think I am seeing, as in so many such projects,  is a disconnect
between what devs think is happening and what bug reporters think is

I agree with your assessment. But until someone starts providing the missing info. I fear there can be no resolution. Ultimately someone from the developer's and/or administrative side of the fence needs to figure out how to resolve this to most people's satisfaction.

For unsubscribe instructions e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.