3.5.3rc1 win32 / debug package ...

[Petr Mladek]

On Fri, 2012-06-01 at 13:10 -0700, bfo wrote:
> Michael Meeks-2 wrote
> > 
> I think it won't do any good in the long term. Enabling reporting tool would
> give you a chance to
> get more data without the need to know the bugzilla magic by the users (just
> opt in to send the reports). 
> It could bring more testers to the project, as now you have to do an own
> debug build to test LO 
> with proper backtraces (especially on Windows).
> Then (or I should write "Before that") you can think about what to do with
> the data (and how). 
> Luckily you can use experience of other projects (nice reading at
> http://blog.mozilla.org/metrics/) 
> or code even and work with dashboards like https://crash-stats.mozilla.com/ 
> or http://brasstacks.mozilla.com/orangefactor for instance. 
> I can see you have quite a few  http://tinderbox.libreoffice.org tinderboxes  
> but the question is - how do you use them for QA? 
> Browsing through QA articles I can feel it is more like - download, run,
> test, report scheme atm.

I hope that we could end here. I also like Launchpad from Ubuntu. It
merges reports with the same backtrace. So, it automatically handles
duplicates. You could easily see how many people are affected and find
the related comments on a single location.

Note that we need to do this step by step. First, we need to have the
builds with debuginfo. Then we need to have infrastructure to filter the
results, handle duplicates, ... Finally, we could enable the reporting
tool.

Note that we already have troubles to filter all the manually created
bugs. We are looking for more people helping with the bug triage, see
http://wiki.documentfoundation.org/BugTriage

If you could help, please step in.

> > 	Anyone is welcome to put / link them into whatever wiki page they
> > like :-) if you want it - go for it ! I'm happy to add a link to it at
> > the bottom of my template so it's easy to find in future.
> > 
> Yea... As wiki.d.o can have 
> http://wiki.documentfoundation.org/TDF/BoD_Meetings TDF BoD meetings  or 
> http://wiki.documentfoundation.org/TDF/Membership_Committee_Meetings
> Membership Committee Meetings  
> I simply do not understand why Engineering Steering Committee Meeting are
> not there. 
> It is very valuable information about what is going on in the project. 
> http://wiki.documentfoundation.org/RBd/TSC_Call_Minutes RBd 's notes are a
> good read, 
> but you know... pasting minutes into wiki template do not need another
> volunteer...

Heh, Michael already does so many things. In fact, he is looking for a
volunteer who could join the call and take the minutes.

Anyway, you might volunteer and take the minutes from the mailing list
and paste them into the wiki. If you prepare the pages and template and
if it is easy to add new week, Michael might do it himself in the
future.


> >> Also I am really concerned about your QA priorities. IMHO you should
> >> care little more about Windows builds and MS Office filters.
> > 	Who is the 'you' here ? you are one of us if you're helping out :-) 
> > [...]
> > 	However, getting the best and fastest possible list of and
> > prioritisation of bugs is a crucial task of QA 
> > 
> By "you" I mean QA Team.

We are still building the QA team. Feel free to join and move forward
some activities.


>  Reading ESC minutes I do not see general rule of
> prioritisation of bugs.

It is pity but we do not have defined rules for prioritization of bugs.
It currently depends on the feeling of the reporters and bug triagers.

Would you be interested into creating such a proposal? You might take
inspiration in the attached document that describes rules for Novell
bugzilla. IMHO, it is reasonable and might fit even LibreOffice. We just
need to use LibreOffice-specific examples.

> Is it 1. crashers 2. regressions 3. enhancements or any other scheme? I
> can't feel it atm. 

We use the keyword "regression" to mark regressions. We motivate
developers to work on these bugs with higher priority.

AFAIK, we do not have any keyword for crashers. IMHO, we use a
workaround because these bugs usually have the work crash in subject.

In each case, Rainer is leading the activities in this area. I am not
sure if he has it described in the wiki. I can't find it easily.


> You have MAB meta bugs, but it's more "my bug is more buggy than your bug"
> attitude there.

This is only a workaround. We do not have enough people to go trough all
reported bugs and standardize the priority and severity flags. Users
tend to set higher severity for their bug, so the original setting is
not useful. MAB is the place for high priority bugs that have been
confirmed by a developer or bug triager.

MAB wont be needed once we have good rules for setting severities and
priorities and enough people who could confirm the original reports.


> >> Sadly I'm not QA specialist. I just decided to help LO project by
> >> confirming as many bugs as I can find in Bugzilla. Hope this will help
> >> increase the quality of LO for Windows in any way...
> > 	Certainly - it's a really good way to help out. 
> > 
> Yes, I started doing that. It seems it moved things a little bit in few bugs
> already.
> Should I do something more?

Yes, any help is really appreciated. If you feel like, please propose
some prioritization. Create the wiki pages about getting the windows
backtrace. Try to review, prioritize, and confirm new bugs. See
http://wiki.documentfoundation.org/BugTriage


>  Maybe, but changing to NEW is quite complicated 
> in your workflow, so mostly I leave them as UNCONFIRMED.

Heh, what is complicated about it? Is the documentation unclear? IMHO,
if you make sure that e bug is reproducible with the given information,
you could move it to the state NEW.


Best Regards,
Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: novell-bugzilla-prioritization
Type: text/x-patch
Size: 4055 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120604/5b495412/attachment-0001.bin>