Re: [Libreoffice-qa] LibreOffice code coverage
Michael Stahl-2 wrote > >> Did anyone make such report for LibreOffice codebase? > no, unfortunately we don't know how the unit test coverage ranks exactly > on a scale from "far too low" to "infinitesimal" :-/ > Hi. Thanks to work of John Smith such report is available at http://dev-builds.libreoffice.org/lcov_reports/. Any comments? Best regards. ___ If you reply to this email, your message will be added to the discussion below: http://nabble.documentfoundation.org/LibreOffice-code-coverage-tp3994901p4003168.html To unsubscribe from LibreOffice code coverage, visit http://nabble.documentfoundation.org/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3994901&code=bGlicmVvZmZpY2UtcWFAbGlzdHMuZnJlZWRlc2t0b3Aub3JnfDM5OTQ5MDF8LTE0NjUxOTE3MDY=___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] LibreOffice code coverage
julien2412 wrote > > There's a tracker about coverage, see > https://bugs.freedesktop.org/show_bug.cgi?id=38840 > For the moment, no one seemed to be on it (perhaps I'm wrong). > Hi. What a discovery! I have found some scripts already in the codebase http://opengrok.libreoffice.org/xref/core/sal/qa/helper/gcov/. Maybe someone with Linux build environment could check that out and try to generate some stats. Best regards. ___ If you reply to this email, your message will be added to the discussion below: http://nabble.documentfoundation.org/LibreOffice-code-coverage-tp3994901p3998038.html To unsubscribe from LibreOffice code coverage, visit http://nabble.documentfoundation.org/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3994901&code=bGlicmVvZmZpY2UtcWFAbGlzdHMuZnJlZWRlc2t0b3Aub3JnfDM5OTQ5MDF8LTE0NjUxOTE3MDY=___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
[Libreoffice-qa] Interoperability of LibreOffice and Microsoft Office 2013
Hi. Microsoft Office Professional Plus 2013 Preview Evaluation is available for download as MSI installer at http://technet.microsoft.com/en-US/evalcenter/hh973391.aspx?wt.mc_id=TEC_114_1_5 (link at the bottom of the page). Windows 7, Windows 8, Windows Server 2008 R2 or Windows Server 2012 required. Both 32bit and 64bit versions are available. It is good opportunity to know what new features will be available in this package and test interoperability with LibreOffice. Product page is available at http://www.microsoft.com/office/preview/en. Best regards. __ If you reply to this email, your message will be added to the discussion below: http://nabble.documentfoundation.org/Interoperability-of-LibreOffice-and-Microsoft-Office-2013-tp3996056.html This email was sent by bfo (via Nabble) To receive all replies by email, subscribe to this discussion: http://nabble.documentfoundation.org/template/NamlServlet.jtp?macro=subscribe_by_code&node=3996056&code=bGlicmVvZmZpY2UtcWFAbGlzdHMuZnJlZWRlc2t0b3Aub3JnfDM5OTYwNTZ8LTE0NjUxOTE3MDY=___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
[Libreoffice-qa] LibreOffice code coverage
Hi. Today I stumbled upon Thunderbird code coverage report (http://people.mozilla.org/~jcranmer2/c-ccov/). Did anyone make such report for LibreOffice codebase? Best regards. __ If you reply to this email, your message will be added to the discussion below: http://nabble.documentfoundation.org/LibreOffice-code-coverage-tp3994901.html This email was sent by bfo (via Nabble) To receive all replies by email, subscribe to this discussion: http://nabble.documentfoundation.org/template/NamlServlet.jtp?macro=subscribe_by_code&node=3994901&code=bGlicmVvZmZpY2UtcWFAbGlzdHMuZnJlZWRlc2t0b3Aub3JnfDM5OTQ5MDF8LTE0NjUxOTE3MDY=___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Cleaning bug list
Petr Mladek wrote > >> I'd change the workflow a little bit by putting the obvious things at the >> top: >> - feature requests aka wishlist > I do not have any strong opinion for this. I think that it is is good to > be able to discuss features, so "enhancement" bugs in bugzilla might be > usable. >> - add target milestone if a feature is planned already > This must be done by developer, anyway :-) > Well, to be clear, I see all this more like how to triage guide, that is why I started with enhancements. Target milestone can be set by QA member if feature is available. https://bugs.freedesktop.org/show_bug.cgi?id=33773#c11 for instance. >> - bugs reported against not supported branches - exclude those at >> reporting >> level by disabling old versions in select fields; but what to do when >> they >> appear anyway - mark them as INVALID at triaging? ask the reporter to >> check >> in new version? Any comments? > We need to be more careful here. The current rule is to do NOT modify > the version picker if you reproduce the problem with newer version. It > is because it is very valuable to know how the bug is old. It helps > developers to locate it. So, maybe, we should do it the other way and > set the field to the oldest version where it was found. > I was thinking about New bug reports, which should be reported for supported branches only (proposed in https://bugs.freedesktop.org/show_bug.cgi?id=51070). Unfortunately it depends on https://bugs.freedesktop.org/show_bug.cgi?id=50198. >> - is it Most Frequently Reported - then just dupe it > What do you mean by "Most Frequently Reported"? > Is it at https://bugs.freedesktop.org/duplicates.cgi for LibreOffice product. Then it can be handled very quickly, but I see that searching for dupes is already listed on http://wiki.documentfoundation.org/BugTriage > I would personally enable voting as well but some other people thing > that it is not objective. > Unfortunately I discovered https://bugs.freedesktop.org/show_bug.cgi?id=39739. WONTFIXed by Mr Bielefeld who authored http://wiki.documentfoundation.org/Vote_for_Enhancement, where it begins with "[...] Bugzilla bug tracking system does not support Votes for requests as it is available for OpenOffice.org. Here you find an experimental Voting (or better: statistical online survey), currently with only very few rules and only for Enhancement requests." I am perplexed. How manual wiki voting, adding special keywords to bugs can be better than automated, build-in, out of the box, customizable voting within Bugzilla? Strange. I know that voting is not a recipe to find best bugs to fix/features to implement, but I think that giving an ability to vote (even only for QA team members or LO developers) would help going forward. I do vote for features in other Bugzillas myself. > You are right, regression are bad and we need to fix them with high > priority. On the other hand, you still need to compare them with other > reported bugs and decide what is more annoying for the daily work. We > could not blindly set the highest priority for a tiny functional problem > just because it is a regression. As someone said, you could view almost > any bug as regression, so we need to prioritize them as well. > I would keep the current approach. Add "regression" into Whiteboard and > set one level higher priority that you would set for non-regression. > I disagree. Many people just won't upgrade because of them. Fast query shows 180 opened bugs with regression keyword. Very worrying... > It actually helps to prioritize bugs as well. If reporter is not willing > to provide more information, the problem is probably not that important > for him. > Disagree, as providing proper bt is complicated. > Also note that some crashers are reproducible only in very strange > circumstances. Also some scenarios are very hard to prepare. We just > need help from reporters in these cases. > Sure, but IMHO only if bug is not reproducible. > If someone change the priority a wrong way, I would ask them not to do > it, explain that the level is not that important, and change it back. If > they change it once again, I would leave it as is. Developers would > filter it themselves :-) > I found https://bugs.freedesktop.org/show_bug.cgi?id=49168. IMHO instead of flooding the Bugzilla, one can just disable it. > I think that it is not worth spending resources on migrating bugs to a > single bugzilla. IMHO, it is better to spend time on fixing other bugs, > improving the functionality, testing, ... > Already some bugs are migrated (from Symphony for instance). Some of them are fixed already. I just can't imagine proper bug management in a project, when you have to follow many bugtrackers. > The ideal process is described at > http://wiki.documentfoundation.org/BugReport_Details#Initial_state > Of course, developers are just humans, sometimes quite overloaded and > they do not follow the process. [...] > develo
