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

[xwiki-devs] [ANN] XWiki 11.4RC1 released
by Alex Cotiugă 21 May '19

21 May '19

The XWiki development team is proud to announce the availability of XWiki 11.4RC1. This release brings important improvements on the management of the conflicts encountered when editing a page as well as better explained messages, displayed to users, to easily understand the occurring issues. Also, a dedicated macro for inserting WikiMacro Content was introduced. 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/11.4RC1 Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [Proposal] Roadmaps for 11.5 and 11.6
by Vincent Massol 21 May '19

21 May '19

Hi devs, Here’s a proposal for 11.5 + 11.6, discussed with Thomas, Marius and Simon already. XWiki 11.5 ========== * BFD: All * Hibernate upgrade to finish - Assignee: Thomas * "Finish the autocomplete of references which has been dropped since Adel left and we still don't have it in the WYSIWYG + implement autocomplete on attachments.”. - Assignee: Marius * Merge on Save: https://jira.xwiki.org/browse/XWIKI-175 - Assignee: Simon Dates: * 11.5RC1: 17 June 2019 * 11.5: 24 June 2019 XWiki 11.6 ========= * BFD: All * Velocity upgrade (too dangerous for 11.2/11.3) - Assignee: Thomas * Security: Add permissions for xobjects to prevent giving all permissions to users with edit rights on a page. - Assignee: Marius (+ Thomas)? * Limit number of login attempts until user gets blocked - http://jira.xwiki.org/browse/XWIKI-15488 - Assignee: Simon ? Dates: * 11.6RC1: 22 July 2019 (added one more week due to the XWiki SAS seminar) * 11.6: 29 July 2019 Others ====== The following item couldn’t be planned for 11.5 or 11.6 due to lack of time/manpower but we should consider it for 11.7+: * Better handling of user removal and transfer of rights ( http://jira.xwiki.org/browse/XWIKI-12142 ) WDYT? @devs: please confirm that you’re ok. @Simon, please let me know if it’s ok for the item where there’s a question mark. @Marius: same for you. @evalica: I didn’t put any investigations/designs but we should IMO. Any proposals? Thanks -Vincent

4 5

[xwiki-devs] Building/Installing XWiki Platform
by Mua Rachmann 16 May '19

16 May '19

Hi there everyone, I am trying to begin my adventure with xwiki and begin contributions. I wish to build the xwiki platform but i ran into some errors. - I have downloaded and installed maven 3.6.1 - I have java v8 and on Mac OS Following the link Vincent provided here See https://dev.xwiki.org/xwiki/bin/view/Community/Building/ When i run **mvn clean install** i get the following error MBP-de-MACBOOK:xwiki-platform rachmann$ mvn clean install [INFO] Scanning for projects... [ERROR] [ERROR] Some problems were encountered while processing the POMs: [FATAL] Non-resolvable parent POM for org.xwiki.platform:xwiki-platform:11.2-SNAPSHOT: Could not find artifact org.xwiki.commons:xwiki-commons-pom:pom:11.2-SNAPSHOT and 'parent.relativePath' points at no local POM @ line 23, column 11 @ [ERROR] The build could not read 1 project -> [Help 1] [ERROR] [ERROR] The project org.xwiki.platform:xwiki-platform:11.2-SNAPSHOT (/Users/rachmann/Documents/open_source/xwiki-platform/pom.xml) has 1 error [ERROR] Non-resolvable parent POM for org.xwiki.platform:xwiki-platform:11.2-SNAPSHOT: Could not find artifact org.xwiki.commons:xwiki-commons-pom:pom:11.2-SNAPSHOT and 'parent.relativePath' points at no local POM @ line 23, column 11 -> [Help 2] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException Any help would be appreciated thanks Regards, Mua

3 14

[xwiki-devs] [XWiki Day] BFD#210
by Oana-Lavinia Florean 16 May '19

16 May '19

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

1 0

[xwiki-devs] [Proposal] WikiMacro inline editing: 2 new dedicated macros
by Simon Urli 14 May '19

14 May '19

Hi everyone, I'm currently working on allowing inline editing on new wikimacros. My first challenge right now is to cope with the problem of inserting the macro content and allowing to inline edit it. In order to do so, I propose to create two new dedicated macro: - wikimacrocontent: would allow to insert and inline edit a wiki macro content - wikimacroparameter: the same for a parameter. The idea would be to be able to write something such as: {{velocity}} {{wikimacrocontent/}} This is a content of $xcontext.macro.content.length() characters. {{/velocity}} So the purpose of those macros would be twofold: 1. to ease the insertion of macro content/parameters (no need to always use {{velocity}}$xcontext.macro.content{{/velocity}} 2. to create the dedicated metadata around the content and to be processed during wikimacro rendering to allow inline editing Of course those macro would be only to be used inside a wikimacro. I started to develop the wikimacroccontent, so I have a first working POC, but I'd like to know WDYT about this. I would also be really happy if you could give me some wikimacro examples where the inline editing would make sense, so I could use it in my tests. Thanks, Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

4 9

[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] [Proposal] Roadmap for XS 11.4
by Vincent Massol 10 May '19

10 May '19

Hi devs, We’re already 10 days into the release so this is coming very late and I apologize. So here’s a proposal for 11.4: * BFD: All * Finish the autocomplete of references which has been dropped since Adel left and we still don't have it in the WYSIWYG + implement autocomplete on attachments. - Assignee: Marius ** Note: this will carry over in 11.5 since Marius won’t have many days available during the 11.4 timeframe * Inline editing of wiki macros - Assiggne: Simon * Hibernate upgrade - Assignee: Thomas * Fix the notifications endless loop: https://jira.xwiki.org/browse/XWIKI-16363 - Assignee: Thomas (note: already done!) Dates: * 11.4RC1: 20 May 2019 * 11.4: 27 May 2019 @committers: if you’re ok please create the relevant jira issues if they don’t exist and assign yourself to them + set the fix version value, and update the roadmap page with the jiras: https://www.xwiki.org/xwiki/bin/view/Roadmaps/ Thanks -Vincent PS: I’ll send proposals for 11.5 and 11.6 real soon.

1 0

[xwiki-devs] Analysis of BFD releases 11.2 and 11.3
by Vincent Massol 08 May '19

08 May '19

I did a quick analysis of 11.2 & 11.3 to see how many bugs we fixed since they were supposed to be BFD releases. The results are not that impressive: * XWiki 11.0 (non BFD): 32 bugs closed * XWiki 11.1 (non BFD) 44 bugs closed * XWiki 11.2 (BFD): 37 bugs closed * XWiki 11.3 (BFD): 54 bugs closed Here’s the graph: https://www.evernote.com/l/AHcQ57uKyNRK-YmB09gvM70OXXVTIhFWcs0 The graph shows that during the period (March and April) we had: * Created issues (128) * Resolved issues (123) So we were not even able to catch up with created bugs during the period. So the question is: why are we not able to catch up? Let’s look at who closed bugs during the period: https://www.evernote.com/l/AHfj3Z0DW8RAuZ0AHw9BX6cnoDZc89KPvog Top resolvers: * Simon Urli - 32 * Thomas Mortagne - 30 * Vincent Massol - 15 * Guillaume Delhumeau - 5 * Marius Dumitru Florea - 2 So one reason is that we roughly have only 2 main issue resolvers (Simon and Thomas) and the other committers are not closing enough. So not enough manpower. Would be interesting to see if we have more bugs being created every month these days when compared to, say, 2 years ago. For ex: * category = 10000 AND type = Bug and created >= 2019-03-01 and created <= 2019-03-31 ** 70 bugs created * category = 10000 AND type = Bug and created >= 2018-03-01 and created <= 2018-03-31 ** 41 bugs created * category = 10000 AND type = Bug and created >= 2017-03-01 and created <= 2017-03-31 ** 46 bugs created * category = 10000 AND type = Bug and created >= 2016-03-01 and created <= 2016-03-31 ** 81 bugs created More generally: * category = 10000 AND type = Bug and created >= 2015-01-01 and created <= 2015-12-31 ** 780 bugs created * category = 10000 AND type = Bug and created >= 2016-01-01 and created <= 2016-12-31 ** 732 bugs created * category = 10000 AND type = Bug and created >= 2017-01-01 and created <= 2017-12-31 ** 609 bugs created * category = 10000 AND type = Bug and created >= 2019-01-01 and created <= 2019-12-31 * 257 bugs created so far. Extrapolates to 257*3 = 771 So it seems we don’t have specifically more bugs being reported in general. So it seems it’s mostly a manpower/focus issue. WDYT? Thanks -Vincent

4 12

[xwiki-devs] [ANN] XWiki 10.11.8 released
by Guillaume Delhumeau 07 May '19

07 May '19

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

1 0

[xwiki-devs] [GSOC] Welcoming our GSoC students
by Eduard Moraru 07 May '19

07 May '19

Hello community, Hello Google Summer of Code students, First of all, congratulations on your applications and your activity during the selection period, and welcome in the XWiki development team. Before guiding the accepted students to their next steps, we'd like to thank again all those who showed interest in XWiki for this Summer of Code. We had a lot of good applications this year, with professional approaches and interesting ideas, and it was very difficult to choose. Unfortunately, some very good students, with great potential, were not accepted. So, to those interested in getting involved anyway, without Google's implication, I renew the invitation to put your ideas in practice under the guidance of the community. Even though the money will be missing, you can still take advantage of the other GSoC benefits: learning new things, gaining experience, earning recognition, etc [1]. If you would like to do that, please let us know by replying to this mail. For the accepted students, here are some getting started hints: = Community bonding period = According to the program timeline [2], the next month (until - May 27th) is to be used for community bonding. The first thing to do, sometime this week, is to present yourself and your project on the dev list, so that everyone knows who you are and what to expect from you. A precondition to being able to send mails to the devs list is to first be subscribed [2.1] to it, which you __need to do ASAP__ if you haven't already. Also, you should continue getting acquainted with the code, the practices and the developers. Please make sure you all read and understand the following - very useful - documents: - [3] http://dev.xwiki.org/xwiki/bin/view/Community/ - [4] http://platform.xwiki.org/xwiki/bin/view/DevGuide/ - [5] http://platform.xwiki.org/xwiki/bin/view/Features/ = Mentorship = We prefer open mentorship. While your assigned mentor is the one officially in charge with your guidance, almost all interaction should be done 'in the open' as much as possible, on the IRC channel or on the mailing list. You should choose the communication medium according to the importance of the matters to be discussed: naturally, the less important issues are to be discussed on IRC/Matrix, while the design decisions, important progress announcements and testing/feedback requests go on the devs list. This way, the community is informed on the evolution of your project, and other developers can come up any time with useful ideas and suggestions. Moreover, if your mentor is "hit by a bus" (the bus factor [6]), another developer can take his place with little effort. = Communication = Sitting alone in your room, working secretly on your project is definitely a __bad__ approach. However, please keep in mind that too much communication can also be harmful, as it distracts the others from their own work. You need to be able to communicate just right: - provide meaningful information about your progress, - ask the community's opinion on non-trivial design or implementation decisions - avoid wasting a lot of time on a problem, when a more experienced developer (or a student that fought the same problem) could quickly provide you an answer; however, do try to find the answer yourself at first. Wrong: "Where do I start? What do I do now? And how do I do that? Is this good? It doesn't work, help me!" Right: "Since a couple of hours ago I get a strange exception when building my project, and googling for a solution doesn't seem to help. Looking at the error, I think that there's a wrong setting for the assembly plugin, but nothing I tried works. Can someone please take a look?" Subscribe to the devs list (if you didn't do this already), and start monitoring the discussions. It is also recommended to register on the users forum, but not mandatory. The notifications list is a little too high volume and technical for the moment, but it is a great knowledge source. Also, try to make sure that you're generally available on chat (IRC/Matrix) in order to have a better view on the daily discussions, get involved and generally be easily reachable, should your mentors or any of the students want to easily get a hold of you. Generally speaking, if you are online (working on your project), you should also be available on the chat, just in case. = Development process = The project's lifecycle is NOT design -> implementation -> testing -> documentation. [7] We invite you to adopt a test driven development [8][9][10] approach and to experience agile development [11]. After the first coding week, you must have some code that works. It won't do much, of course, but it will be the seed of your project. Every functionality will be validated by tests. The code must be properly tested and commented at the time of the writing (don't think you'll do that afterwards, because in most cases you won't). Since our code is hosted on GitHub [12], you should register an account there and fork some xwiki repositories, so that you can try to build XWiki from sources, and be able to contribute bugfixes. We'll add you to the xwiki-contrib organization [13], and we'll create dedicated repositories for each project. We encourage you to do __at least__ weekly commits (ideally, if you are well organized, you should be able to commit code that works daily, so try to aim at daily commits). This way, the code can be properly reviewed, and any problems can be detected before they grow into something too difficult to fix. One big code blob committed at the end, no matter how good it may seem, is a failure at several levels. A simple way of having something functional in the first week is to prepare the maven build for your modules, which will give you the first unit test for the first class. = Next steps, in a nutshell = - Get more familiar with the code and development process and try to master Maven, JUnit, Selenium, component driven development, ... - Continue fixing a few small issues, chosen so that they are __related to your project__. You can ask on IRC for help selecting good issues, or you can pick from the (non-comprehensive) list of easy issues [14] -- This will help you get more familiar with the code your project needs to interact with. - Refine and organize the ideas concerning your project (you can use the Drafts space [15]), and write several use case scenarios. - Start writing the first piece of code for your project. At the end of the community bonding period, you should have a clear vision of the project, well documented on the xwiki.org wiki, you should have the build infrastructure ready, and you should be pretty familiar with the existing code you will need to interact with. And, of course, you should be familiar with the community and the way we communicate. Good luck, and may we all have a great Summer of Code! -The XWiki Development Team ---------- [1] http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/ [2] https://developers.google.com/open-source/gsoc/timeline [2.1] https://dev.xwiki.org/xwiki/bin/view/Community/Discuss#HMailingLists [3] http://dev.xwiki.org/xwiki/bin/view/Community/ [4] http://platform.xwiki.org/xwiki/bin/view/DevGuide/ [5] http://platform.xwiki.org/xwiki/bin/view/Features/ [6] http://en.wikipedia.org/wiki/Bus_factor [7] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ [8] http://en.wikipedia.org/wiki/Test-driven_development [9] http://www.amazon.com/dp/0321146530/ [10] http://www.amazon.com/dp/0201485672/ [11] http://www.amazon.com/dp/0596527675/ [12] https://github.com/xwiki/ [13] https://github.com/xwiki-contrib/ [14] https://jira.xwiki.org/secure/IssueNavigator.jspa?mode=hide&requestId=10510 [15] http://dev.xwiki.org/xwiki/bin/view/Drafts/

1 0