November 2018 - xwiki-devs@xwiki.org

[xwiki-devs] [ANN] XWiki 10.10-rc-1 released
by Guillaume Delhumeau 21 Nov '18

21 Nov '18

The XWiki development team is proud to announce the availability of XWiki 10.10-rc-1. For users, this version brings a protection when a page containing an XClass is moved or renamed. By default, the PDF export looks better now. In addition, the recent auto-suggestion feature has been enabled in a few places. For developers, a new asynchronous framework has been created. It allows the execution of desired parts of the rendering of a page to be executed asynchronously, with an AJAX request. This makes the rendering of the page faster, making the least important parts visible after the page is loaded. Among other things, Wiki Macros can now have typed parameters and it is now possible to make the content of a macro editable inline with the WYSIWYG editor. To finish, more than 30 bugs have been fixed since XWiki 10.9. 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/10.10RC1/ Thanks for your support -The XWiki dev team

2 2

[xwiki-devs] [Proposal] Roadmap for XS 10.11
by Vincent Massol 21 Nov '18

21 Nov '18

Hi devs, Here’s a roadmap for XS 10.11 which is the last release of the 10.x cycle/year. Goal: Mostly stabilization release (bug fixing and last moment polishing of features introduced in the 10.x cycle) * All: BFD (20%) * Thomas/Vincent: Improve STAMP KPIs (20%) * All: Bug fixing/small polishing focus on items added during 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") * Thomas: More async/caching of UIX. * Thomas: Bug: https://jira.xwiki.org/browse/XWIKI-14635 : Unsupported character exception is warned in console when downloading attachment Dates: * 10.11RC1: 17th of Dec 2018 * 10.11Final: 24th-31st of Dec 2018 (I’m putting a range since it’s Christmas and we don’t know who’ll be there) Let me know if you have remarks/questions. Thank you -Vincent

1 3

[xwiki-devs] [Proposal] Jobs for the multiple configuration testing
by Vincent Massol 20 Nov '18

20 Nov '18

Hi devs, I’m still not sure but FTM I was thinking of having 2 pipeline jobs: 1) Job 1: Execute one functional test only (e.g. MenuIT for now) but on the maximum number of configurations, in order to flesh out configs that don’t start properly. For example XWiki on Tomcat 9.x would fail (since the Tomcat 9.x docker image uses java9+). The job would not send a mail on failure but it would update a report page (could even update a page on xwiki.org directly or if too complex update some page on maven.xwiki.org somewhere). This job would run not very often but say once per week. Note that one config takes 3-4 minutes to run, so 50 configs would take 3 hours which is acceptable. 2) Job 2: Execute all functional tests on a subset of supported configs. For example we don’t need to run all the tests on PostgreSQL/Jetty/Chrome if we already run on PostgreSQL/Tomcat/FF and MySQL/Tomcat/Chrome. This job will take a long time to execute. We’ll start with 3-4 configs and will go to about 10 configs when we add more. The tests will take roughly 2 hours to execute per config I think. So a total of 20 hours when we have 10 configs. If we run those once per week it should be fine. Note: Once we have job 1 & 2, we won't need to have the smoke tests I add as part of the platform JenkinsFile. WDYT? Thanks -Vincent

5 10

[xwiki-devs] [Proposal] Always add a link to the reference doc in the RN items
by Vincent Massol 20 Nov '18

20 Nov '18

Hi devs, This is something I mentioned a few times (just did on IRC/matrix an hour ago too) but I don’t know if we have an agreement about to, so I’m making a proposal. The idea is that I think it would be nice for users to be able to the read the RN and for each item to be able to navigate to the reference documentation to know more about the topic. Thus the proposal is to always add a link to the reference doc in RN items. For example I added a link here: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.10RC1/#HAll… When I created the RN app I had hesitate to have a field for that but I thought it be nicer if the links were in the text (better flow) and it would take less visual space (if we have a field we’ll need to add the info somewhere which will take more space). The downside is that everyone is forgetting to do it and it's not enforceable automatically. WDYT? Thanks -Vincent

6 5

[xwiki-devs] Postpone of XWiki 10.10-rc-1
by Guillaume Delhumeau 19 Nov '18

19 Nov '18

Hello. To let Marius finish his work, I propose to postpone the release of XWiki 10.10-rc-1 to tomorow. Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

1 0

[xwiki-devs] Slightly improved default pdf export look and feel
by Anca Luca 18 Nov '18

18 Nov '18

Hello devs, I've whipped up quickly a couple of changes to the default PDF export of the XWiki platform, to try to make it look a little nicer. I created the issue here https://jira.xwiki.org/browse/XWIKI-15761 and the pull request here https://github.com/xwiki/xwiki-platform/pull/900 . I would like to merge that into master unless somebody has something against it, so please speak up now. Longer story: I know that "nicer" is a subjective term, and that a lot more can be done to improve this default PDF export. My idea was that the current defaults we have (for the font family, for example, or the information we display in the pdf header/footer and the style associated) are not the result of an actual studied choice, iirc they are just defaults that were set like that in the first version of that export and never changed. Thus, I don't see why we couldn't slightly change these defaults (without changing the information displayed or risking regressions) to have a slightly better looking default PDF, while still allowing all customizations just they way they worked before. These modifications are not blocking nor replacing in any way the more serious improvements that can be done on the PDF export, they're just slightly improving the current defaults. Best regards, Anca

2 7

[xwiki-devs] [XWiki Day] BFD#197
by Oana-Lavinia Florean 16 Nov '18

16 Nov '18

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

1 1

[xwiki-devs] [Need proposal] How to show "conflicting" macro parameters
by Thomas Mortagne 16 Nov '18

16 Nov '18

Hi xwikiers, In the contact of bringing new Page concept (OK 7.4 is starting to get old) to the API and macros too we decided (1) to introduce a "page" shortcut property (even if we keep the reference/type for other types). While it's nicer for wiki syntax, one issue is that on WYSIWYG macros UI side, which display all properties, it means ending up with conflicting parameters that needs to be displayed as such. I don't really have much clue on how best to display this so I'm searching for ideas :) Then I will add in the macro descriptor what's required for whatever UI we want to build (group and sub groups of properties, etc.). 1: http://design.xwiki.org/xwiki/bin/view/Proposal/DeprecatingSpaceAndSpaceRef… Thanks, -- Thomas Mortagnes

4 37

[xwiki-devs] [Proposal] Update servlet container support strategy
by Vincent Massol 13 Nov '18

13 Nov '18

Hi devs, We now have https://dev.xwiki.org/xwiki/bin/view/Community/ServletContainerSupportStrat… but it’s not precise enough. I’m proposing the following: * Mention the supported version cycle and mention that we support the latest version of the cycle. * For Tomcat, I propose to say we support Tomcat 8.x (which means Tomcat 8.5.34 as of today, see “latest” tag on https://hub.docker.com/_/tomcat/) * For Jetty (standalone packaging or standard), I propose to say we support Jetty 9.x (which means Jetty 9.4.12 as of today, see “latest” tag on https://hub.docker.com/_/jetty/) WDYT? Thanks -Vincent

5 14

[xwiki-devs] [UX] Simpler Upgrades
by Ecaterina Moraru (Valica) 12 Nov '18

12 Nov '18

Hi devs, I've heard that the upgrade process is a complicated process and relies on a lot of manual operations. I haven't investigated the technical solutions we have at our disposal, but I tried to image the desired UI an Administrator would want when upgrading: * be notified that a new version is available: https://design.xwiki.org/xwiki/bin/download/Proposal/Upgrade/SimplerUpgrade… * have an upgrade section in Administration where Distribution and Extensions can be checked for new versions and upgraded / backed: https://design.xwiki.org/xwiki/bin/download/Proposal/Upgrade/SimplerUpgrade… https://design.xwiki.org/xwiki/bin/download/Proposal/Upgrade/SimplerUpgrade… A more detailed proposal at https://design.xwiki.org/xwiki/bin/view/Proposal/Upgrade/SimplerUpgrade/ So, what are your thoughts on this? Thanks, Caty

3 6