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

[xwiki-devs] [XWiki Day] BFD#204
by Oana-Lavinia Florean 18 Jan '19

18 Jan '19

Hello devs, This Thursday is BFD#204: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -31 bugs over 120 days (4 months), i.e. we need to close 31 bugs to have created bugs == closed bugs * -137 bugs over 365 days (1 year) * -147 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#204 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14356 Good luck at fixing bugs, Lavinia

1 1

[xwiki-devs] [proposal] Don't rely on depth anymore for HeadingLevelSplittingCriterion
by Simon Urli 15 Jan '19

15 Jan '19

Hi everyone, I'm working on the document splitter in order to fix the following issue: https://jira.xwiki.org/browse/XWIKI-13100 However I noticed that the current implementation of the document splitter relies on the XDOM depth. That means if an user wants to split a document with header level 1, the header blocks have to be under the root of the document, they cannot be under a GroupBlocks, or as it's the case in XWIKI-13100, under a NumberedListBlock. Moreover, currently we do not rely at all on the header block level for the splitting: if you have a header level 2 under the root and you decided to split the document with header level 1, it will be splitted since only the document depth is used. So I propose to change this behaviour and to rely on HeaderBlock header level *only* for the splitting criteria: the depth won't be used anymore. In practice I propose to keep the API of SplittingCriterion which defines the method with depth parameter, but to not rely on this parameter in the HeadingLevelSplittingCriterion implementation, that we rely on for splitting imported office document. WDYT? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

1 0

[xwiki-devs] [ANN] XWiki 10.11.1 released
by Adel Atallah 15 Jan '19

15 Jan '19

The XWiki development team is proud to announce the availability of XWiki 10.11.1. This is a bugfix release that covers important issues that we have discovered since 10.11 has been released. Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.11.1 Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [XWiki Day] BFD#203
by Oana-Lavinia Florean 11 Jan '19

11 Jan '19

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

1 1

[xwiki-devs] [Proposl] Improve JIRA resolution and introduce a "Solved by" resolution
by Vincent Massol 10 Jan '19

10 Jan '19

Hi devs, Right now we often use “duplicate” when we have an issue that is solved by another issue (usually a more specific one). This is not semantically correct. Proposal: * Add a new jira resolution named “Solved by” * Best practice: when using “solved by”, also use the “depends on” link WDYT? Thanks -Vincent

7 7

[xwiki-devs] [Global Coverage] Modules to check having lost more than 3% since 2017-12
by Vincent Massol 10 Jan '19

10 Jan '19

Hi devs, Would be great if we could check these big TPC regressions since 2017 (see http://maven.xwiki.org/site/clover/20190110/XWikiReport-20171222-1835-20190…) xwiki-platform-rendering-wikimacro-api 89.2753 82.1678 -7.1075 -0.0206 xwiki-platform-icon-script 36.2068 28.9156 -7.2912 -0.0093 xwiki-platform-jodatime 36 20 -16 -0.0077 xwiki-platform-bridge 78.0612 72.1698 -5.8914 -0.0072 xwiki-platform-wiki-script 89.2405 84.1772 -5.0632 -0.0051 xwiki-platform-icon-api 100 84.1269 -15.873 -0.0029 xwiki-platform-notifications-script 80.9523 61.9047 -19.0476 -0.0025 xwiki-platform-wiki-template-default 58.5937 55.4687 -3.125 -0.0025 xwiki-platform-instance 65.625 62.5 -3.125 -0.0012 xwiki-platform-velocity-xwiki 88.2352 76.4705 -11.7647 -0.0012 xwiki-platform-rest-api 50 40 -10 -0.0009 xwiki-platform-localization-script 82.5396 79.3814 -3.1582 0.0008 xwiki-rendering-syntax-xwiki20 96.1586 92.1161 -4.0424 0.0015 xwiki-platform-refactoring-default 84.9557 81.6112 -3.3445 0.0104 I’ve listed all modules for which we lost more than 3% global TPC. Would be great if each of us take 1or 2 to analyze (and fix if it’s a real problem). Thanks -Vincent

1 0

[xwiki-devs] [Proposal] Improve our Test Coverage strategy (TAKE 2)
by Vincent Massol 10 Jan '19

10 Jan '19

Hi devs, We started discussing a first global test coverage strategy in https://markmail.org/message/grphwta63pp5p4l7 I’d like to propose some updates and tuning now that we have a Clover Jenkins pipeline working (brainstormed with Simon): Here’s the new proposal: * We run the Clover Jenkins pipeline every night (between 11PM-8AM) * The pipeline sends an email whenever the new report has modules lowering the global TPC score compared to the baseline report (negative contribution per module) * 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. Options: * Make it easier and only fail the pipeline job when the global TPC value is lower than the baseline (vs failing whenever a module has negative contribution) WDYT? Thanks -Vincent

5 9

[xwiki-devs] [Proposal] Include Cycle release notes in the RN LT
by Vincent Massol 08 Jan '19

08 Jan '19

Hi devs, This is especially for Caty who created: * https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki7x/Summa… * https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki8x/Summa… * https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki9x/Summa… * https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki10x/Summ… Right now these summaries don’t appear on https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ I’m proposing to simply add a ReleaseNotes.Code.ReleaseNoteClass xobject to them so that they can appear in the RN LT, and to use the following xproperty values: * Product: XWiki * Version: 7.x, 8.x, 9.x, 10.x * Is released: true * Release Date: 31/12/<year> The alternative is more complex and involves creating a new XClass for Cycle Summaries and modifying the home page to list cycle summaries in a LT (so that it can scale). Of course we could also do a lightweight version by simply having a link on the home page to a cycle summary page listing links to individual summaries. It would be less visible but could be acceptable. However, the best and easiest is for me to add the ReleaseNotes.Code.ReleaseNoteClass xobjects to Cycle RN pages. WDYT? Thanks -Vincent

2 6

[xwiki-devs] Hibernate upgrade
by Adel Atallah 07 Jan '19

07 Jan '19

Hi devs, As you may know, we are currently using a pretty old version of Hibernate in XWiki and we could benefit from its upgrade. The new version should bring many bug and security fixes (even though they don't all apply to our current version) along with better APIs and the possibility to integrate other tools (such as other / newer libraries or a better connection pool such as the one mentioned in [1]) Currently, I've been trying to make the following upgrades: * 3.6.9 to 4.0.1 * 4.0.1 to 4.3.11 * 4.3.11 to 5.0.12 The goal is to arrive at version 5.4.0, which is at this date the latest stable version. I chose to make the upgrade step by step to avoid having to much issues to solve at once. So far, I've made a pull request ([2]) that you can check for the 4.0.1 upgrade. Here are some of the issues that I've encounter during the upgrades: 3.6.9 to 4.0.1: * Conflicting dependencies: I had to exclude some dependencies in the pom file. * The org.hibernate.Session#connection method removal [3]: I'm either using the Session#doWork method or the Session#createSQLQuery one. * The org.hibernate.connection.ConnectionProvider interface has changed: I had to adapt the DBCPConnectionProvider class that we have, mostly to keep backward compatibility, using C3P0ConnectionProvider as a model. * The Session#getSession(EntityMode) method has been removed [4]: I have no idea how to replace that so we need to test it properly. * Some attributes in org.hibernate.cfg.Configuration have been removed: This has mostly an impact on the custom mapping injection which we need to check. 4.0.1 to 4.3.11: * A change in the hibernate schema update generation makes the update fail [5]: I had to add a property in the hibernate file but I don't think this is the best solution. 4.3.11 to 5.0.12: * The org.hibernate.cfg.Configuration has changed again removing many methods that we were using There are some other issues that I've not mentioned or discovered yet. So for me the biggest issues are: * The schema update: I think we should start using the hibernate one instead of our own (except for migration made with liquibase). * The custom mapping injection: We will need to rewrite it a bit if we want to upgrade to 5.x. The goal for now is to make the 4.0.1 upgrade work. Please let me know what you think or if you have any questions. Thanks, Adel [1] https://jira.xwiki.org/browse/XWIKI-8286?focusedCommentId=96486l#comment-96… [2] https://github.com/xwiki/xwiki-platform/pull/1012 [3] https://hibernate.atlassian.net/browse/HHH-2603 [4] https://hibernate.atlassian.net/browse/HHH-6330 [5] https://hibernate.atlassian.net/browse/HHH-8162

2 1

[xwiki-devs] [Proposal] Roadmap for XS 11.0
by Vincent Massol 07 Jan '19

07 Jan '19

Hi devs, New year, new cycle starting! :) Here’s a proposal for XS 11.0 (already discussed with devs from XWiki SAS). The idea of XS 11.0 is double: * Finish leftovers from 10.11.x * Start important refactorings that can be dangerous XS 11.0 - January ================= Goals: * Finish important leftovers from 2018 * Do some refactoring/core changes since they may require time to stabilize Leftovers from 10.x: * Marius/Adel: Auto complete of references in WYSIWYG Macro Dialog (+ grouping feature so that users don't get both "page" and "reference" at the same time + "deprecated"/"priority" to show "page" more proeminently than "reference") * Simon: Import: make it work with new versions of Libre Office (idea: use a more recent fork of jodconverter, we identified one and check if we need to merge changes we did in our fork) * All: Fix all WCAG failing tests and more generally move to WCAG 2.1 (https://www.w3.org/TR/WCAG21/) - Rationale: usability through accessibility, current failing test reducing trust in CI * Thomas: Fix filesystem storage: https://jira.xwiki.org/browse/XWIKI-15620 New topics: * All: BFD (Priority on Notifications for Guillaume) * STAMP research project: Vincent(30%) * FASTEN research project: Vincent (20%) + Thomas (30%) * Marius: Ability to rename an AWM app * Simon: Fix caching of JS resources forcing reload when upgrading XWiki. Especially for the Navigation Panel. * Adel: Upgrade to Hibernate 5.x * Thomas: Move to Velocity 2.x Dates: * 11.0RC1: 21st of Jan 2019 * 11.0: 28th of Jan As usual: * Feedback welcome especially if you don’t think something is doable * Any other contributor/committer who want to do something for XS 11.0 is free to add more stuff here to the list * Devs: This proposal is now live on https://www.xwiki.org/xwiki/bin/view/Roadmaps/. Please edit and list (create them if need be) the individual JIRA issues needed for your tasks. Thanks -Vincent

1 0