April 2018 - xwiki-devs@xwiki.org

[xwiki-devs] [Brainstorming] Loss of TPC from 2017-11-09 to 2018-04-03
by Vincent Massol 16 Apr '18

16 Apr '18

Hi, I’ve posted the following on matrix/IRC. Friday: * Guys we regressed in global TPC from 2017-11-09 to 2018-04-03 :( * From 76.28% to 75.88% * we need to analyze more in details now to understand why * (and whether the report is correct or not) * PDF Report: https://up1.xwikisas.com/#mJ0loeB6nBrAgYeKA7MGGw * Examples: ** com.xpn.xwiki.internal.store from 97.6% to 89.32% ** com.xpn.xwiki.internal.file from 67.9% to 9.87% - that's huge maybe some refactoring ** org.xwiki.url.internal from 86.99% to 63.69% Today: * Note that I have 2 reasons for checking our TPC: ** Globally it has to go up every year and we've gone down since nov 2017 ** For STAMP we need to show an increase in TPC and we had a nice +2.2% increase from 2016 to 2017 but we've gone down now and we need to go up, to go to +3 or/ 4% at end of 2018 Today I’ve also started analyzing the drop from 67.9% to 9.87% for “com.xpn.xwiki.internal.file”. Here are my findings: * This is caused by TemporaryDeferredFileRepository which is no longer tested ** Before: http://maven.xwiki.org/site/clover/20171109/clover-commons+rendering+platfo… ** After; http://maven.xwiki.org/site/clover/20180403/clover-commons+rendering+platfo… * There have been refactoring recently to enable FS attachment store by default that have led to TemporaryDeferredFileRepository not being used anymore (deprecated methods not used anymore) or used only in some specific circumstances (for example at https://github.com/xwiki/xwiki-platform/blob/ac85d61b0c48d7ed21a8109e964f77… the store is not defined) * The conclusion is that before the changesTemporaryDeferredFileRepository was called a lot (indirectly) leading to 545 calls to it (http://maven.xwiki.org/site/clover/20171109/clover-commons+rendering+platfo…) and now it’s not called anymore at all. * The second conclusion is that we had no unit/integration tests for it and the changes lead to loosing it being tested. So it’s no longer tested ATM. Thanks to the Clover report we noticed that it’s no longer tested. * Thus we need to do one of 2 things: ** Move the code to legacy and make sure no code uses it. That’s if we don’t really need it ** Keep it but add some unit/integration tests or even some functional tests that would trigger it. I’ll let Thomas pitch in on this. Next step: analyze some other drops in TPC. Note: I wish it were simpler to find out why some TPC drops. Took me like 1-2 hours to figure all this out... Thanks -Vincent

1 2

[xwiki-devs] [Proposal] New JUnit5 test framework for XWiki Components
by Vincent Massol 15 Apr '18

15 Apr '18

Hi devs, I’ve had some fun this week end implementing the equivalent of MockitMockingComponentRule, MockitoComponentManagerRule & ComponentManagerRule (and more). See https://jira.xwiki.org/browse/XCOMMONS-1392 for more details. Let me know what you think. If we don’t like it I can remove it for 10.3RC1 or 10.3 final. FTR I’ve read https://junit.org/junit5/docs/current/user-guide/#overview and I find JUnit5 so powerful :) I love it. Thanks -Vincent

1 1

[xwiki-devs] [XWiki Day] BFD#172
by Alex Cotiugă 13 Apr '18

13 Apr '18

Hello devs, This Thursday is BFD#172: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is:-640 bugs since the beginning of XWiki. Since we're upgrading the JIRA version, other statistics are unavailable at the moment. Here's the BFD#172 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14190 Happy Bug Fixing Day, Alex

1 1

[xwiki-devs] [Brainstorming] EvoCrash usage on XWiki?
by Vincent Massol 09 Apr '18

09 Apr '18

Hi devs, Context ====== Evocrash is a tool developed as part of the STAMP research project (https://www.stamp-project.eu/) Its goal is to take a stack trace (the use case is production stack traces) and generate a test that, when executed, reproduces the stack trace ;) It’s using Guided Genetic Algorithm to simplify the search space (which is pretty cool, isn’t it? ;)). More info at https://github.com/STAMP-project/EvoCrash and http://www.evocrash.org/ Results ====== So far evocrash was able to generate tests for the following issues (I’ve pasted the generated test code as comment): * https://jira.xwiki.org/browse/XRENDERING-422 * https://jira.xwiki.org/browse/XWIKI-14475 * https://jira.xwiki.org/browse/XWIKI-13031 * https://jira.xwiki.org/browse/XWIKI-13196 * https://jira.xwiki.org/browse/XWIKI-13916 Using ===== The use case I see is the following: * A user reports a problem when using XWiki and create a jira issue with a stack trace * An XWiki dev finds it and runs evocrash to generate a test reproducing the problem * The XWiki dev uses the test to understand the reason (breakpoints can be put in the IDE) of the problem and writes a better test (which can be inspired by the test generated by evocrash or be completely different). Questions ======== The question we need to answer is whether we think it coud be useful or not. Are there cases where it can be useful? For example if we imagine someone not knowing the xwiki code base well, maybe this can help him/her understand the bug in a simpler way than just having to read/find where the problem is in the code base? I’ve started the work of trying to evaluate how useful it could be on the XWiki project by analyzing the examples above. I've only analyzed 2 ATM (see the links in the jira comments) and I’d be interested to have your analysis too. WDYT? Thanks -Vincent

2 4

[xwiki-devs] Survey Personas 2017
by Ecaterina Moraru (Valica) 02 Apr '18

02 Apr '18

Hi devs, I've analyzed the 31 responses we got on the XWiki Feedback form in 2017. The purpose was to know our users better and to try to define some personas. http://design.xwiki.org/xwiki/bin/view/Proposal/SurveyPersona It would be nice to have more data to analyze or to know which users we want to target / focus on when deciding what to prioritize for development. Let me know if you find the findings interesting and if they match your hypothesis. The pool is not that big and is relative. Thanks, Caty P.S. We also have some older stats on these responses that can be used for comparison on http://www.xwiki.org/xwiki/bin/view/Blog/XEFeedbackSummary

1 0

[xwiki-devs] [Proposal] e.x.o improvements: grid, icons, colors
by Ecaterina Moraru (Valica) 02 Apr '18

02 Apr '18

Hi devs, Here are some ideas about how the repository application used on extensions.xwiki.org could look like if we were to provide multiple display layouts for extensions, require the contributors to add custom icons, colors and screenshots. http://design.xwiki.org/xwiki/bin/view/Proposal/exoGrid In terms of design I tried to make it look as a proper application store, but it will be heavily influenced on users providing ratings for extensions and contributors on providing quality icons / colors/ description / screenshots. In terms of interaction, the biggest change would be a revamp of the search functionality. Currently users are using it, but it's a generic search, focused on text results. Let me know what you think, Caty P.S. Proposal ideas iterated with Marius, Alex and Eduard.

4 4