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

Hi :)
Interesting thought and a good diagram, thanks :)  

Something i have wondered for a while is how to utilise what this particular list has to offer, 
perhaps confirming bug-reports could be partially done through this list?

Occasionally someone new on this list expresses an interest in getting more involved or somehow 
repaying the community.  Also this list is quite good at eventually pinning-down exactly what an 
initial question was probably really asking.  

People here generally don't have much time or experience but might be willing to push a couple of 
buttons to see if something really doesn't work, especially if it's not risky.  

Could we have a weekly report listing  unconfirmed bug-reports generated during the week?  Would it 
be easier to have a link that listed all the 'thousands' of unconfirmed bug-reports?  Is it 
thousands or (as i suspect) much much lower?  

Ideally it would be great to have devs doing development rather than devs spending time trying to 
work at customer-relations and guessing at what people meant by certain bug-reports.  

Just my 2pence-worth
Regards from
Tom :)  

--- On Thu, 16/8/12, Andrew Brager <> wrote:

From: Andrew Brager <>
Subject: Re: [libreoffice-users] Re: Excuse me, but your opinion is simply unimportant. Start over 
and you can expect more of the same.
Date: Thursday, 16 August, 2012, 1:16

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

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.