April 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] [VOTE] Officially support for Tomcat 9
by Thomas Mortagne 31 Jul '19

31 Jul '19

Hi devs, tomcat9 package is now available in Debian repositories so I would like to start providing xwiki-tomcat9-* Debian packages of XWiki. Nothing complex so far but it if we provide an official tomcat 9 oriented package it would also make more sense to add Tomcat 9 in https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletConta… (only Tomcat 8 right now). Another argument is that it's the current recommended stable version from Tomcat point of view so people will use it more and more. WDYT ? Here is my +1 -- Thomas Mortagne

3 13

[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

Re: [xwiki-devs] XAR source projects should allow source files
by paul＠hoplahup.net 03 May '19

03 May '19

>> On 26 Aug 2016, at 13:50, Vincent Massol wrote: [...] >> * What I understand is that you’re not proposing to change the XAR >> format but to introduce some tooling to generate a XAR from a set of >> source files, at build time. Correct? [...] I am rewaking this rather older subject (see http://xwiki.475771.n2.nabble.com/XAR-source-projects-should-allow-source-f… and older things mentioned there) with yet another attempt which might satisfy everyone: an attempt to use XAR-Transformations to include files into XARs. It defines two extra transformations: - INSERT_TEXT (using an XPath expression): inserts the content of the text file - INSERT_ATTACHMENT_CONTENT (using a file name): inserts the content of a file in base64 The attempt is detailed in https://jira.xwiki.org/browse/XCOMMONS-1614 and has a pull-request and an example realisation. I claim that this attempt allows project developers to nicely edit files and let them be combined into a xar when it is the time. See the issue for an example realisation. I would love your comments. Paul

3 2

[xwiki-devs] [Proposal] Define Xmx value in jvm.config for xwiki-* repositories
by Vincent Massol 30 Apr '19

30 Apr '19

Hi, Since Maven 3.3.1 it’s possible to declare default command line options and JVM options, see https://maven.apache.org/docs/3.3.1/release-notes.html It could be interesting to do so in our repos so that all users run with the right values. Or we could decide that the values depend too much on the profiles being executed and it’s not worht it. WDYT? Thanks -Vincent

2 1