March 2019 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] Use discourse for the "dev" mailing list
by Guillaume Delhumeau 18 Sep '19

18 Sep '19

Hi devs, I think we are now satisfied with our experimentation with the "users" mailing list on discourse. I propose you to move the "dev" ML too. My main point is that it allows advanced formatting (which is good when you have complex proposals), meanwhile the formatting is lost with our archiving tool like markmail (it's plain text). Here is my +1. Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

3 5

[xwiki-devs] [Proposal] Cleaning of flickering tests
by Simon Urli 06 Sep '19

06 Sep '19

Hi everyone, I was checking our list of flickering tests in JIRA (https://jira.xwiki.org/issues/?jql=labels%20%3D%20flickering%20AND%20status…) and I noticed that we had somehow old flickering test issue concerning test that I've never seen failing. So I propose we close some of them as inactive: the ones that we don't remember having seen for a while. The ideal would be to have a mechanism to update the issue when the CI fails on a flicker, but it takes time to do properly and it's not a priority. On the contrary I propose to trust our memory: if we're wrong because we have closed a flicker that is still happening, it will allow us to remind that we have this flicker to fix and we can easily reopen the issue. As Thomas mentioned on the chat, we should also update the release plan to include the inactive flickers in the list of issue to check. So for now I propose to close the following list of issues as inactive: * XWIKI-14399: AddRemoveTagsTest#addAndDeleteTagFromTagPage is flickering (https://jira.xwiki.org/browse/XWIKI-14399) * XWIKI-14396: AnnotationsTest#addAndDeleteAnnotations is flickering (https://jira.xwiki.org/browse/XWIKI-14396) * XWIKI-14394: SectionTest.testSectionEditInWikiEditorWhenSyntax2x (xwiki-enterprise-test-ui) is flaky (https://jira.xwiki.org/browse/XWIKI-14394) * XWIKI-14386: appwithinminutes.AppsLiveTableTest.testEditApplication is possibly flaky (https://jira.xwiki.org/browse/XWIKI-14386) * XWIKI-14835: DeletePageTest#deletePageIsImpossibleWhenNoDeleteRights is flickering (https://jira.xwiki.org/browse/XWIKI-14835) * XWIKI-14860: LoginTest#testDataIsPreservedAfterLogin is flickering (https://jira.xwiki.org/browse/XWIKI-14860) And I propose in general to close the flickers we don't remember having seen after a cycle as inactive. WDYT? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

3 20

[xwiki-devs] [Proposal] Update database support strategy
by Vincent Massol 05 Jun '19

05 Jun '19

Hi devs, We currently have https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy However, it doesn’t say explicitly which versions we officially support: * For HSQLDB it says 2.3.3 which is wrong since the latest version is 2.4.1 * For MySQL it says 5.x but doesn’t specify which specific version(s) * Same for other DBs We cannot really support every versions since supporting means testing too. So what I propose: Question 1: definition * We say we support the latest stable version of the databases for a given version cycle ** For MySQL, it’s the latest of the 5.x cycle, which is 5.7.24 as of today (see https://hub.docker.com/_/mysql/) ** For PostgreSQL, it’s the latest of the 9.x cycle, which is 9.6.10 as of today (see https://hub.docker.com/_/postgres/) ** For Oracle, it’s the latest of the 11.x cycle, which is 11.2.0.4.0 as of today (see https://www.oracle.com/technetwork/database/enterprise-edition/downloads/in…) Question 2: review what we support * For MySQL I think we could also start supporting MySQL 8.x (ie the latest version of that cycle). We have an issue open for it currently: https://jira.xwiki.org/browse/XWIKI-15215 * For PostgreSQL we could also start supporting versions 11.x (ie the latest version of that cycle) * For Oracle, we could also start supporting versions 12.x (ie the latest version of that cycle) Question 3: decide if we drop some support * Is there any cycle that we should support for? Right now I think that MySQL 5.x is still heavily used, same for postgreSQL 9.x I guess. Don’t know for Oracle. * Any idea? So WDYT about the 3 questions? Thanks -Vincent

7 32

[xwiki-devs] [Proposal] Do not write pure-developer release notes
by Vincent Massol 31 May '19

31 May '19

Hi devs, Context ======= It’s been since we’ve deviated from the original purpose of the Release Notes by also adding developer-oriented release notes. The goal of the Release Notes was to **highlight** important novelties for our **users**, because looking at the JIRA list is too technical (otherwise we could simply use the Release feature of JIRA! :)). So you may ask why we do have a “Developer” Category in the RN app. These were not for pure developers but for XWiki users who are more advanced and can write scripts in wiki pages. And when it’s the case we **must** add examples, otherwise, it’s completely useless. For example this morning I saw this RN added: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.0/Change004/ This is typically something that has very little value to me: * It’s for pure developers (java devs) * It’s not understandable by anyone except the person who coded it or participated to the dev mailing list discussion about it * It doesn’t say more than what’s in the JIRA issue so what’s the point? * There are no examples at all in it! * Real developers can simply look at the reference documentation or can read the JIRAs. We always link the JIRA issues in the RN anyway (it was for this reason that we’re listing them). * It takes time to write RN items and thus it needs to have high value Proposal ======== * Go back to the original idea and only list developer RN items when they are for scripting users and not APIs. For example, document some new script service or some additions to existing script services. Of course Groovy would allow you to call any API so being able to use it from Groovy is not a good criteria. I’d say that the criteria should be whether the Release Note Change is useful for Velocity users. * Rename “Developers” into “Scripters” or or “Advanced Users” (any better name?) * Always put an example when writing a “developer” change and take the time to explain properly what it’s about. WDYT? Thanks -Vincent

6 14

[xwiki-devs] OpenCollective for XWiki Community
by Ecaterina Moraru (Valica) 23 May '19

23 May '19

Hi devs, This is a proposal for the content we would have if we were to create an OpenCollective account for XWiki. Take a look at https://design.xwiki.org/xwiki/bin/view/Proposal/XWikiOpenCollective The issues we need to solve / validate are: A. Decide on the URL name (xwiki is already taken by XWiki SAS) B. See if XWiki SAS can act like our Fiscal host C. Validate the tiers and content https://design.xwiki.org/xwiki/bin/view/Proposal/XWikiOpenCollective#HTiers (we might need more details on how the "Bug Fixer" works in case we agree to it) Let me know what you think, Caty

2 14

[xwiki-devs] Location for extensions ideas
by Thomas Mortagne 23 May '19

23 May '19

Hi xwikiers, I'm never sure where to put ideas of extensions I have so I often forget them or details I had tough about or gathered back then. I don't think http://design.xwiki.org is the right place until you really start designing the extension. Also it's too generic for this need and not a very good entry point for searching something IMO, more something to link to from somewhere else. I would prefer something really dedicated to this "that would be a nice thingy but not sure about the details yet" state. Would be a good source for hackathons and GSOC or for contributors who are searching for something interesting to work on. I was thinking about the following alternatives: * a new dedicated project on https://jira.xwiki.org * reuse https://jira.xwiki.org/projects/XCONTRIB after some cleanup (close everything left in it basically) but not super clean (it's just that it's a good name) * some new application on http://www.xwiki.org WDYT ? Right now my preference goes to a clean new jira project (just need to think about a good project id) where you put description and close it when the extension work really start on a dedicated location. Less work and should do the job well. -- Thomas Mortagne

4 7

[xwiki-devs] [proposal] Process to handle Pull Requests
by Ludovic Dubost 10 May '19

10 May '19

Hi devs, I don't think there is currently a process that is in place to handle pull requests and I have the feeling that the way there are handled today is a bit random. There are usually comments sent out on each pull request but sometimes it seems that some pull requests are going in sleep mode and it's not clear who is in charge. I would like to suggest that a process is put in place where it's clear who is responsible for a pull request and a status is given to the contributors that propose that pull request. Something like: Assigned developer: XXXX Status: New -> new pull request, not yet assigned Assigned -> assigned to a developer, he is in charge of reviewing the pull request and ask for modifications or accept it. The developer can auto assign it to himself. If nobody does, we need to decide how they will be taken into account. ModificationsRequired -> for now rejected with comments. Contributor needs to apply comments and then change back to Assigned for further evaluation VoteRequired -> there are no more comments, but a vote is required as the changes to XWiki core are important WaitingFinalAuthorization -> optional step for complex patches where a additional authorization would be required (need to define who would be the persons that give the authorization) WaitingApplication -> there are no more comments and no changes or vote required. The pull request can be applied and is waiting for a developer to apply it Abandoned -> contributors is abandoning the pull request (cannot do the changes, no more time, etc..) Rejected -> pull request is rejected (quality not enough, etc..) Applied -> pull request is applied What do you think ? Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

7 12

[xwiki-devs] [Brainstorming] Failing build when deprecated APIs are used in scripts?
by Vincent Massol 03 Apr '19

03 Apr '19

Hi devs, I'd like to discuss about introducing a checker in the tests to fail the test if there's a warning message about a deprecated APIs being used in scripts. For example: ``` 23:59:28.308 [main] INFO org.xwiki.test.ui.TestDebugger - GroupIT-addUserAndSubgroupToGroup started 23:59:32.593 [Exec Stream Pumper] ERROR o.x.t.i.XWikiLogOutputStream - 2019-03-28 23:59:32,593 [http://localhost:8080/xwiki/bin/view/XWiki/XWikiPreferences?xpage=getgroups…] WARN o.x.v.i.DefaultVelocityEngine - Deprecated usage of method [com.xpn.xwiki.plugin.rightsmanager.RightsManagerPluginApi.countAllMembersNamesForGroup] in 21:/templates/getgroups.vm@62,37 23:59:35.824 [Exec Stream Pumper] ERROR o.x.t.i.XWikiLogOutputStream - 2019-03-28 23:59:35,824 [http://localhost:8080/xwiki/bin/view/XWiki/XWikiPreferences?xpage=getgroups…] WARN o.x.v.i.DefaultVelocityEngine - Deprecated usage of method [com.xpn.xwiki.plugin.rightsmanager.RightsManagerPluginApi.countAllMembersNamesForGroup] in 18:/templates/getgroups.vm@62,37 23:59:41.349 [Exec Stream Pumper] ERROR o.x.t.i.XWikiLogOutputStream - 2019-03-28 23:59:41,348 [http://localhost:8080/xwiki/bin/view/XWiki/XWikiPreferences?xpage=getgroups…] WARN o.x.v.i.DefaultVelocityEngine - Deprecated usage of method [com.xpn.xwiki.plugin.rightsmanager.RightsManagerPluginApi.countAllMembersNamesForGroup] in 21:/templates/getgroups.vm@62,37 23:59:58.503 [main] INFO org.xwiki.test.ui.TestDebugger - GroupIT-addUserAndSubgroupToGroup passed ``` Rationale: * This adds warnings in the xwiki logs when users navigate to those pages which isn’t nice. * It also helps reducing the number of deprecated methods we use (I have the feeling this is not reducing) and helps us move towards being able to move the deprecated code to legacy. WDYT? Thanks -Vincent

5 8

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

03 Apr '19

Hi devs, I remember that we talked about this new global test coverage strategy but I don’t recall where and I couldn’t find an email about it. So I’m reposting the strategy that I’ve just finished implementing. * Every day the Clover job runs: https://ci.xwiki.org/view/Tools/job/Clover/ * It generates a global coverage report and compares it automatically with the first report generated for the current version * If the global coverage is reduced, then: ** an email is sent to notifications(a)xwiki.org containing the report ** the job is marked as FAILING ** A failing badge is added to the job history ** A red large text is added to the job page and a link to the report is sent * Developers MUST fix the global coverage before we can release a version, so the it means the global coverage must not be reduced during a version. * The RM should check the CI (already part of his chores) and the “Recommended Failing” view on ci.xwiki.org must not have errors or failures (so that includes pitest job and clover job). Any comments? Does that seem ok to you? If you confirm it’s ok, I’ll document it on https://dev.xwiki.org/xwiki/bin/view/Community/Testing/TestCoverage/ Note: A few minutes ago an email has been sent since the global coverage has been reduced compared to yesterday. See http://maven.xwiki.org/site/clover/20190321/XWikiReport-20190320-0128-20190… So we need to fix it now. Thanks -Vincent

3 2

[xwiki-devs] [ANN] XWiki 10.11.4 released
by Ecaterina Moraru (Valica) 28 Mar '19

28 Mar '19

The XWiki development team is proud to announce the availability of XWiki 10.11.4. This is a bugfix release that covers important issues that we have discovered since 10.11.3 has been released. 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.11.4 Thanks for your support -The XWiki dev team

1 0