- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Proposal] Disallow / and \ in page names by default
by Vincent Massol 23 Feb '19

23 Feb '19

Hi devs, Because of tomcat and because tomcat is by far the most used container for xwiki and because we also bundle tomcat in the debian and docker dsitributions, I think we should disallow / and \ in page names by default. It's causing too much trouble for users. We keep having users posting problems and for one user who post a problem there are 100 who don't. The latest one: https://forum.xwiki.org/t/please-help-broken-link-routing-cannot-open-page-… Implementation idea: * Offer an extension point in the create page UI to allow plugging some cleaning algorithm * Provide the \ and / cleaning algorithm by default * Handle backward compat. Find ways to not break existing users who are having / and \ in page names. For example we could imagine a property in xwiki.properties that we would set to point to the hint of the / and \ cleaner component. Thus existing users would need to voluntarily upgrade their xwiki.properties to have it if they want it. We would need to provide some script to convert existing pages with / and \ too probably. WDYT? Thanks -Vincent

2 5

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

22 Feb '19

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

1 1

[xwiki-devs] [ANN] XWiki 11.1 RC1 released
by Marius Dumitru Florea 19 Feb '19

19 Feb '19

The XWiki development team is proud to announce the availability of XWiki 11.1 RC1. This release adds support for renaming apps created with App Within Minutes and brings improvements to the WYSIWYG editor: inline editing of the Box Macro title and macro category count displayed by the Macro Selector. Advanced users can now copy the page reference from the Information tab at the bottom of each page. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.1RC1/ Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [contrib] Page Preview Popover extension request
by Stéphane Laurière 19 Feb '19

19 Feb '19

Hi all, I would like to contribute an extension that will display page preview popovers when hovering wiki links, similarly to what MediaWiki offers: https://www.mediawiki.org/wiki/Page_Previews https://blog.wikimedia.org/2018/05/09/page-previews-documentation/ Its name could be 'application-page-preview-popover' - what do you think? As discussed with Caty yesterday, the extension will use the Bootstrap popovers. Should you have any need or suggestion, please let me know. If the name is ok, can I ask you for the creation of a repository and JIRA project? Stéphane -- Stéphane Laurière XWiki www.xwiki.com @slauriere

6 10

[xwiki-devs] [Proposal] XS 10.2 and 10.3 roadmaps - Bug fix releases
by Vincent Massol 19 Feb '19

19 Feb '19

Hi devs, We have already started defining the roadmap for XS 10.2, see https://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki11.2 However, it’s come to my realization that we’re having a lot of stability issue on XS these days. I see plenty of users messages on the forum about users failing to use XWiki or to upgrade XWiki and having problems in general. I have the feeling that our quality has regressed. If we check our number of bugs created vs number of bugs closed for 2018, we can clearly see that we’re loosing the battle since Feb/March 2018, see: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352#Created-vs-… Since Feb/March we’re at 820 vs 963 which means we have a relative difference of 143 bugs. Note that the BFD sessions are not enough and they don’t close a lot of bugs anymore (this can be seen on https://www.xwiki.org/xwiki/bin/view/Blog/XWiki%20Days) I believe that XWiki’s stability and reducing user frustration for installation/upgrades is a key aspect and it’s one of the biggest possible contributor to Active Installs. Thus I’m proposing to devote 2 releases (i.e. 2 months) to focus on bug fixing and thus on XWiki stability, namely * XS 10.2 * XS 10.3 Note that this is something that I’ve already discussed with committers from XWiki SAS. Please voice your opinion if you disagree (or even if you agree, always good to get confirmation we’re going in the right direction ;)). Thanks -Vincent

2 3

[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