April 2018 - 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] 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] [Discussion] Coding practice for location of internal package name
by Vincent Massol 31 Dec '18

31 Dec '18

Hi devs, On Matrix/IRC, I’ve posted the following: " * Guillaume Delhumeau: BTW your naming is strange for the internal package * for ex: package org.xwiki.notifications.preferences.internal.email; * normally we put internal just after the main package part * ie. * org.xwiki.notifications.internal.* * and org.xwiki.notifications.* for public classes * see http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/JavaCodeStyle/#HPac… * General rule is org.xwiki.(module name).internal. * I see thomas has done the same “error" for org.xwiki.job.handler.internal and org.xwiki.job.handler.internal.question . So maybe there's something to discuss/change * I guess we have a mix of both now so we should discuss it and adjust our rules if need be “ So I think we don’t have all the same rules/understanding of the definition at http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/JavaCodeStyle/#HPac… I’d like to discuss with you to see what you prefer and adjust our rules so that it matches what we do in practice. Any take in this? Thanks -Vincent

7 8

[xwiki-devs] [Brainstorming] Finish refactoring for xwiki configuration directories
by Vincent Massol 25 Dec '18

25 Dec '18

Hi devs, Context ====== Clemens fixed a bug at https://jira.xwiki.org/browse/XWIKI-15163 and while doing so inroduced a new system property to override the location of the xwiki.properties file. I commented at https://jira.xwiki.org/browse/XWIKI-15163?focusedCommentId=98075&page=com.a… Even though it’s not necessary to introduce a new system property just for the need of this test (it’s easy to refactor the code to not need this IMO), it raises the question of what we want to do to make the configuration simpler in XWiki (simpler config, simpler upgrades, etc). History ====== We discussed this a few times in the past: * March 2010: http://markmail.org/message/6cvm5hocvtbqtgp6 * June 2012: https://markmail.org/message/3aq2bjrb6a2ip2ri Note that the June 2012 proposal was agreed. Globally this is what we implemented since the June 2012 proposal: * XCOMMONS-187: The Permanent Data directory resolver should support System Property "xwiki.data.dir". More specifically the code is here: https://github.com/xwiki/xwiki-commons/blob/55569d3466dc0ea36f6964474973f7a… * XWIKI-13867: Search xwiki.cfg in /etc/xwiki/ first. Code is here: https://github.com/xwiki/xwiki-platform/blob/973d4e9c6ad02dbb31d94fe96df9c1… * XWIKI-13868: Search xwiki.properties in /etc/xwiki/ first. Code is here: https://github.com/xwiki/xwiki-platform/blob/93f02215783ac0f4030fe3062cac4d… I’d like to note that I don’t remember discussions/proposals for XWIKI-13867/XWIKI-13868 and I commented on http://jira.xwiki.org/browse/XWIKI-13867 and didn’t get any response from my various comments. Current behavior ============= So right now the behavior is the following on config files (I’m excluding the recent change of Clements, see below in actions): * If xwiki.cfg exists under the. "java:comp/env” JNDI key, then it’s used * If not found, then search for it in /etc/xwiki/xwiki.cfg * If not found, then default to WEB-INF/xwiki.cfg * If /etc/xwiki.xwiki.properties exist then it’s used * if not found, search in WEB-INF/xwiki.properties (as a ServletContext resource) * If not found, then default to an empty configuration Discussion/Proposal ================ * I think we should ask Clemens to rollback the introduction of the xwiki.properties.default.dir system property and to just make the test work without introducing any system property. I can help Clemens do that. * I propose that instead we continue implementing the June 2012 proposal defined at https://markmail.org/message/3aq2bjrb6a2ip2ri and introduce the xwiki.config.dir system property. * Right now I don’t like the solution introduced by /etc/xwiki/* because they don’t allow supporting several instances of XWiki on the same machine. However, the introduction of xwiki.config.dir system property would fix it. * We could also introduce the user home dir location as a location where xwiki config files would be looked for. * We also need to generalize the config files to hibernate.cfg.xml and clustering config files (jgroup files), and logback. See https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Backup#HConfi… WDYT? Thanks -Vincent PS: Sorry for the long mail, I had to do a lot of archeology to research this… Took me a while ;)

2 2

[xwiki-devs] [VOTE] Add new check to measure quality of tests
by Vincent Massol 06 Jul '18

06 Jul '18

Hi devs, As part of the STAMP research project, we’ve developed a new tool (Descartes, based on Pitest) to measure the quality of tests. It generates a mutation score for your tests, defining how good the tests are. Technical Descartes performs some extreme mutations on the code under test (e.g. remove content of void methods, return true for methods returning a boolean, etc - See https://github.com/STAMP-project/pitest-descartes) If the test continues to pass then it means it’s not killing the mutant and thus its mutation score decreases. So in short: * Jacoco/Clover: measure how much of the code is tested * Pitest/Descartes: measure how good the tests are Both provide a percentage value. I’m proposing to compute the current mutation scores for xwiki-commons and xwiki-rendering and fail the build when new code is added that reduce the mutation score threshold (exactly the same as our jacoco threshold and strategy). I consider this is an experiment to push the limit of software engineering a bit further. I don’t know how well it’ll work or not. I propose to do the work and test this for over 2-3 months and see how well it works or not. At that time we can then decide whether it works or not (i.e whether the gains it brings are more important than the problems it causes). Here’s my +1 to try this out. Some links: * pitest: http://pitest.org/ * descartes: https://github.com/STAMP-project/pitest-descartes * http://massol.myxwiki.org/xwiki/bin/view/Blog/ControllingTestQuality * http://massol.myxwiki.org/xwiki/bin/view/Blog/MutationTestingDescartes If you’re curious, you can see a screenshot of a mutation score report at http://massol.myxwiki.org/xwiki/bin/download/Blog/MutationTestingDescartes/… Please cast your votes. Thanks -Vincent

6 12

[xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector
by Claude Brisson 20 Jun '18

20 Jun '18

Hi. I'm currently working on Velocity 2.0 packaging. If that's OK with you, I would like to incorporate DeprecatedCheckUberspector.java into Velocity, but I need a statement from your part to be able to change its licence to Apache 2.0 (LGPL and Apache 2.0 licences aren't compatible). By the way, I take this opportunity to tell you that if there is another specific part of xwiki-commons-velocity that you think should be integrated on our side, or an important missing feature you'd like to insist on, don't hesitate. I already integrated VELOCITY-825, for instance, so String->Enum constant conversions are now handled by Velocity. There may be other important conversion cases you'd like to see handled. Regards, Claude

4 8

[xwiki-devs] [Page type] What about Main.WebHome
by Thomas Mortagne 18 May '18

18 May '18

Hi xwikiers, In 10.3 I introduced a "home" type with Main.WebHome in mind with the following defaults: * edit allow * delete forbidden * no upgrade if modified I tough that deleting the wiki home page was not so great. Eduard argue that since the wiki home page is configurable there is no reason to restrict delete right. WDYT ? I feel that most people don't change the configured home page so I'm +1 to keep it like this but I'm not strongly against allowing delete if others think it's fine since I don't have much experience with configured home page use case. -- Thomas Mortagne

3 4

[xwiki-devs] Onboarding feedback
by Adel Atallah 11 May '18

11 May '18

Hello everyone, I've been following the onboarding tracks 1 and 2 on the past days, here is what I can say: The first track really helped me to get started in XWiki contributions as I could easily pick a jira issue to work on. The issue description was clear even though we had to discuss it on the chat. Speaking of the chat, it has been a very valuable tool, people have been very responsive and I was rarely stuck. I found the development practice a bit inconvenient at first, having to make changes in the vm files of my XWiki instance and then report the changes to the sources. I would have love to see a way to link my source files (especially for vm/js/css files) with the one of my XWiki instance to avoid errors when I copy past my changes (and get benefit of my git ecosystem). The second track is a good introduction to some XWiki concepts, I don't have much to say for this one. A link to a real application could maybe give a better understanding. Thanks again for the help I had! <http://www.xwiki.com/> *Adel Atallah* *Product developer intern* adel.atallah(a)xwiki.com <corina.luong(a)xwiki.com> tel: +33 (0)6 12 96 35 06

6 6

[xwiki-devs] [NEW API] XAR entry type
by Thomas Mortagne 07 May '18

07 May '18

Hi devs, When dealing with extension pages protection we ended up with a very visible issue: EVERYONE customize the home page so it does not make much sense to warn every user trying to edit it that it's dangerous and might break the extensions. Since it's not the only use case 10.3 introduce the concept of XAR entry type which allow controlling a bit more edit/delete and upgrade behavior. See http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+Module+Specificati… for more details. On component side it's possible to decide the default type of a page reference (that's where "Main.WebHome" type come from currently). It's also possible to override the upgrade behavior for a specific type or even a specific reference for more exotic use cases. So it's now possible to control the type you want for a page at XAR descriptor level. I already typed a few page, for example "Main.WebHome" is now of type "home" which means "it's OK to edit it and you should only upgrade it if no customization have been made". Cool home page is covered but we now entered a new era of endless debates to decide of what type some page should be and what other types to introduce :) We are not going to discuss all these in this mail so everyone with a doubt should start a discussion for a standard page (or a set of standard page which are obviously very similar like color themes). Currently, protected page produce a warning that you can force. The plan in 10.4 is to keep the warning only for advanced completely prevent basic user to modify protected pages by default and also allow configuring all that (indicate in your profile that you don't want to be bothered with that, override edit/delete right even for advanced users, etc.). But before that we need to make sure basic users are allowed to edit all the pages they are supposed to edit. Happy tuning :) -- Thomas Mortagne

4 12

[xwiki-devs] [Vote] Assignee for PR: Contributor or Committer?
by Ecaterina Moraru (Valica) 07 May '18

07 May '18

Hi, We have discussed this subject multiple times, but we don't have an official vote and conclusion on the topic. Problem: In JIRA who is the Assignee of an issue fixed by a Pull Request? 1: Contributor - he provided the solution - giving the attributions, the contributor might feel encouraged to contribute more - we could do some JIRA statistics on external contributions, but this use case can be covered by GitHub statistics 2: Committer - he does the merging on his account and he becomes responsible for the committed code. - in case there are problems, the committer needs to find solution, since we can't rely on contributors availability - in doing the PR review, the committer spends a lot of time analyzing and testing the provided solution We are talking here about complete solutions provided by the PR, since in case of partial solutions, the committer can assign himself on the issue (depends on the quantity of modification he does). Let me know what you think, Caty

9 11