February 2019 - xwiki-devs@xwiki.org

[xwiki-devs] [XWiki Day] BFD#207
by Oana-Lavinia Florean 15 Feb '19

15 Feb '19

Hello devs, This Thursday is BFD#207: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -17 bugs over 120 days (4 months), i.e. we need to close 17 bugs to have created bugs == closed bugs * -151 bugs over 365 days (1 year) * -136 bugs over 500 days (between 1 and 2 years) * -334 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#207 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14399 Good luck at fixing bugs, Lavinia

1 1

[xwiki-devs] [Proposal] New Functional test best practice for docker-based tests
by Vincent Massol 12 Feb '19

12 Feb '19

Hi, Now that JUnit 5.4.0 is out we have test ordering. I propose the following best practices for TC-based docker tests: @UITest @TestMethodOrder(OrderAnnotation.class) public class MenuIT { @Test @Order(1) public void verifyMenuInApplicationsIndex(TestUtils setup) { ... } @Test @Order(2) public void verifyMenuCreationInLeftPanelWithCurrentWikiVisibility(TestUtils setup) { ... } @Test @Order(3) public void verifyMenuIsAvailableInAdministration(TestUtils setup) throws Exception { … } Instead of the current: @Test public void verifyMenu(TestUtils setup) throws Exception { verifyMenuInApplicationsIndex(setup); verifyMenuCreationInLeftPanelWithCurrentWikiVisibility(setup); verifyMenuIsAvailableInAdministration(setup); } Pros: * Easier to run each test * Easier to debug and view recorded video for a specific failing test * More in sync with JUnit’s practices * It’s still a scenario and thus doesn’t incur penalty of extra test setup Cons: * Starts and stop the VNC docker container for each test. It takes between 1 and 2s to start the VNC container and the stop (i.e. video recording save) should be the same as before. So I think it’s worth it. Out of 3mn, 3-6 more seconds for 3 tests is not too much (between 2% and 3% more). WDYT? Thanks -Vincent

2 4

[xwiki-devs] [ANN] New committer: Simon Urli
by Vincent Massol 12 Feb '19

12 Feb '19

Hi Devs, The XWiki committers have voted a new committer: Simon Urli. Welcome as a committer Simon :) @Simon: Congrats, and thank you for the work you’ve done so far. Keep it up. See https://dev.xwiki.org/xwiki/bin/view/Community/Committership We’ll add you to the various places. Thanks -Vincent

8 8

[xwiki-devs] [Proposal] Improve our Test Coverage strategy (TAKE 3)
by Vincent Massol 11 Feb '19

11 Feb '19

Hi devs, After TAKE 2 (see http://markmail.org/message/owtyhkmrz4tcbymn ), and after analyzing several modules (I analyzed about 4-5 in total), I think we should improve a bit the strategy to make it usable and applicable. Lessons learnt ============ * It takes a lot of time to analyze a single global tpc drop (every time it takes me around 2 hours) * In general the results of the analysis are not that great. There are often “good enough” reasons for the drop. It’s often a lack of unit tests and code that is exercised by functional tests but the path has changed for various reasons. * I find the ratio of time to spend on the analysis vs result to be too low. * In the end what’s important is that our global TPC continues to grow New Strategy =========== * We run the Clover Jenkins pipeline every night (between 11PM-8AM) * The pipeline sends an email whenever the new report has its global TPC going down when compared with the baseline (vs one or more modules had their TPC lowered in TAKE 2) * The baseline report is the report generated just after each XS release. This means that we keep the same baseline during a XS release ** Technically it means that the pipeline will update the latest.txt file (which contains the clover report timestamp) when it notices a version change * We add a step in the Release Plan Template to have the report passing before we can release. * The RM is in charge of a release from day 1 to the release day (already the case), and is also in charge of making sure that the global coverage job failures get addressed before the release day so that we’re ready on the release day. * Implementation detail: don’t send a failure email when there are failing tests in the build, to avoid false positives WDYT? Thanks -Vincent

4 4

[xwiki-devs] On Global TPC report and failing tests for 20190202
by Vincent Massol 10 Feb '19

10 Feb '19

Hi devs, FYI I’ve analyzed the job log for http://maven.xwiki.org/site/clover/20190202/XWikiReport-20190101-2330-20190… and found that: * The report only shows 3 failing tests (excluding WCAG+validation) when in practice there are 44 failing tests… * Some of them are being we’re missing the clover jar in some classpath * Others are flickers * Others are failing because of the clover instrumentation The list of failing tests can be seen at http://maven.xwiki.org/site/clover/20190202/clover-commons+rendering+platfo… Note that the numbers there are not correct. See also https://massol.myxwiki.org/xwiki/bin/view/Blog/GlobalLocalCoverage#HAdditio… So there’s work to do before we can have a good global coverage value we can believe in. On short: we should be better than what is indicated. Thanks -Vincent

1 0

[xwiki-devs] Analysis of TPC loss on xwiki-commons-job since 2019-01-01
by Vincent Massol 10 Feb '19

10 Feb '19

Hi Thomas and all, I’ve just done the analysis of the xwiki-commons-job TPC loss displayed on http://maven.xwiki.org/site/clover/20190108/XWikiReport-20190101-2330-20190… (and it’s still the case today on http://maven.xwiki.org/site/clover/20190202/XWikiReport-20190101-2330-20190…) xwiki-commons-job 84.3812 84.2416 -0.1395 -0.0002 There were only 2 classes that have had changes in TPC: * DefaultJobProgress - lowered TPC * AbstractRequest - increased TPC But there’s more lowering than increasing globally which is why it’s in red. Specifically the lowering happened in 2 places: * http://maven.xwiki.org/site/clover/20190108/clover-commons+rendering+platfo… vs http://maven.xwiki.org/site/clover/20190101/clover-commons+rendering+platfo… * http://maven.xwiki.org/site/clover/20190108/clover-commons+rendering+platfo… vs http://maven.xwiki.org/site/clover/20190101/clover-commons+rendering+platfo… Note that no source code changed in the job module. Conclusions: * It was hard to track and I need to improve the report to show a package level difference too and not just modules, at least for modules going down. Actually, even better would be a class level difference too for modules going down. * In this case, I believe we had some bugs in XWiki somewhere that led to hitting the "Could not find any matching step for source [{}]. Ignoring EndStepProgress.” error. Could someone confirm that, it rings a bell to me? * It also shows there’s no module level tests (ie unit tests) that go on in this IF and it would be good to add one to prove that we get a log when we have an end without a start. It’s interesting because this is a use case where our global TPC went down because we fixed a bug (and thus indirectly we enter into less code). It mostly highlights that we don’t tests this case and we should. Thanks -Vincent

1 1

[xwiki-devs] Update objects on class rename
by Marius Dumitru Florea 09 Feb '19

09 Feb '19

Hi devs, I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page rename job (from refactoring module) to update the existing objects when a class is renamed *if the "Update links" options is checked*. Of course, we could add a new option (e.g. "Update objects") but: * it complicates the rename UI (too many options) * I think most of the users understand the current "Update links" option as "update the places where this page is *used*". I don't think it makes sense to have separate options (at least at the UI level) for things like "Update macro calls" or "Update image includes". * I don't see why you would want to update the back-links but not the objects (or the other way around). If we agree on using a single option ("Update links") then the next questions are: * Is there a better name? I think "Update links" is a good name for simple users so I would keep it. Another option is "Update references" but it has a special meaning for XWiki developers. * Should we update the hint for the "Update links" option? I think we should, but only for advanced users, since they should be aware of the implications of renaming a class. Simple users are not aware of the existence of objects, most probably, so I wouldn't complicate their lives. The final question is whether we should keep the rename job question about classes. I think we should. The reason we added it is because renaming a class is currently dangerous. Updating the objects makes it a bit less dangerous because the data is preserved, but classes are often used in scripts (e.g. a live table) and those scripts are not updated so there's a high chance that something will not work correctly after the class rename. WDYT? Thanks, Marius

6 17

[xwiki-devs] [XWiki Day] BFD#206
by Oana-Lavinia Florean 08 Feb '19

08 Feb '19

Hello devs, This Thursday is BFD#206: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -16 bugs over 120 days (4 months), i.e. we need to close 16 bugs to have created bugs == closed bugs * -144 bugs over 365 days (1 year) * -140 bugs over 500 days (between 1 and 2 years) * -328 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#206 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14397 Good luck at fixing bugs, Lavinia

1 1

[xwiki-devs] [Proposal] Get rid of Activity Stream and the Watchlist
by Guillaume Delhumeau 07 Feb '19

07 Feb '19

Dear developers, Now that we consider notifications as an achieved replacement for both Activity Stream and the Watchlist, I propose to stop maintaining them and to move them into the "attic" section. You need to know that we had a dependency on the Activity Stream API, as the only implementation of the Event Stream, on which the Notifications are based. So to get rid of this dependency (the code is not using our component system and is not well tested), I have written a new implementation of the Event Stream that I have called "Event Stream Store". It's fully backward compatible with the old implementation, since it is using the same Database schema. In practice, I re-used some pieces of Activity Stream that I have modified to fit into components. For more information, see: https://jira.xwiki.org/browse/XWIKI-16052 So my proposal is this one: - use the new store in 11.1 - stop bundle Watchlist and AS in 11.1 - move Watchlist and AS into "attic" in 11.2 Thanks you, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

5 7

[xwiki-devs] [contrib] Open Graph Protocol extension request
by Stéphane Laurière 04 Feb '19

04 Feb '19

Hi devs, As a follow-up to the issue below, I'd like to propose the creation of an extension for adding Open Graph Protocol support to XWiki pages : https://jira.xwiki.org/browse/XWIKI-16087 Hence my request: would you approve the creation of an "application-open-graph-protocol" repository in xwiki-contrib, and an OGP project in JIRA? Cheers, Stéphane -- Stéphane Laurière XWiki www.xwiki.com

2 3