xwiki-devs December 2017

xwiki-devs@xwiki.org

15 participants
19 discussions

[xwiki-devs] [VOTE] Use discourse for the "dev" mailing list

by Guillaume Delhumeau

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

5 years

[xwiki-devs] [proposal] Process to handle Pull Requests

by Ludovic Dubost

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

5 years, 4 months

[xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector

by Claude Brisson

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

6 years, 3 months

[xwiki-devs] [Vote] Assignee for PR: Contributor or Committer?

by Ecaterina Moraru (Valica)

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

6 years, 5 months

[xwiki-devs] BaseObject ID collisions

by Marc Sladek

Dear XWiki devs We are using the XWiki platform for our applications but sadly are still stuck with 2.7.2. Lately we ran into issues on a large database and noticed "disappearing" BaseObjects. We were able to link it to XWIKI-6990 <http://jira.xwiki.org/browse/XWIKI-6990>, where hibernate IDs collided (hash collisions) and overwrote other objects without any trace - neither visible in the history nor in a log file. We analysed your implemented solution from 4.0+ in XWikiDocument <https://github.com/xwiki/xwiki-platform/blob/stable-8.4.x/xwiki-platform-co…> and BaseElement <https://github.com/xwiki/xwiki-platform/blob/stable-8.4.x/xwiki-platform-co…> and noticed that you changed the 32bit String#hashCode to 64bit MD5, which makes a collision less likely. I have a few questions regarding your solution: 1) Is there any specific reason why you have chosen MD5 over SHA-1 or 2? 2) Collisions are still possible and would be extremely hard to notice since they are completely silent. Have you considered to implement a collision detection to at least log occurring collisions - or even better reserve 1-2bits of the 64bit to be used as collision counter in the case of it happening? 3) To question the concept of generating a hash for an ID in general: Wouldn't a database defined "auto increment" be a much more robust solution for the hibernate IDs? A collision would be impossible and clustering/scalability is still possible with e.g. the InnoDB “interleaved” autoincrement lock mode. Why have you chosen a hash based solution in the first place? I'm sorry if these questions were already answered in the dev mailing list or on issues, please link me to them since I couldn't find any concrete answers. Thanks for your time and regards Marc Sladek synventis gmbh

6 years, 7 months

[xwiki-devs] [Brainstorming] Implementing multi-environment tests - Take 2

by Vincent Massol

Hi devs, I wanted to give you some info on what I’m doing for implementing multi environment testing on XWiki. Initially I thought about this architecture (let’s call it the "running maven inside docker” strategy): http://massol.myxwiki.org/xwiki/bin/view/Blog/DockerJenkinsConfigurationTes… However after more thinking, I think it’s not the best solution. I’m now exploring the “‘running docker inside maven” strategy which works as follows: The generation of the docker image + the start/stop of the docker containers is done by the maven build itself. This has the following advantages: * It’s not dependent on the CI system used * It allows the build to be reproduced locally on dev machines (only prerequisite is to have docker installed - note that right now the prerequisite is to have FF installed locally and we would swap this req. in favor of docker) * We’ll generate the official xwiki docker images as part of our build and not anymore as some external build/steps to execute * The build will be done fully with Maven (no more gradle) FYI, the plugin I’m exploring for this is the fabric8.io one: https://dmp.fabric8.io/#introduction I’ve started the work locally and I’ll commit once I have something ready enough. Let me know if you have some opinion or questions about this. Thanks -Vincent

6 years, 9 months

[xwiki-devs] A subtle problem with the Workflow Application and nested pages

by Clemens Robbenhaar

Hi Devs, some users reported a problem to me concerning the Publication Workflow Application and the nested pages feature. The problem is as follows: In their old instance (some 6.4.x) they had a draft space and a public space and workflows attaching each page in the draft space with a page in the public space in an 1:1 manner, like: Draft.WebHome --> Public.WebHome Draft.PageA --> Public.PageA Draft.PageB --> Public.PageB Now if a link in, say, PageA in the Draft space points to another page, e.g. PageB, this is done via a relative link like [[link text>>doc:PageB]] After publishing PageA, the link of the published variant points to the published variant of PageB (and not the variant in the Draft space), which is the desired effect from the users point of view. Now after migration to 9.10 the situation is as follows: Draft.WebHome --> Public.WebHome Draft.PageA.WebHome --> Public.PageA.WebHome Draft.PageB.WebHome --> Public.PageB.WebHome Now a link to PageB in PageA looks like: [[link text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the same space, but each in their own space. Publishing the draft makes the link in the published variant point back to the Draft space, of course. However this is different from the behavior before nested pages and the users experience this as a bug. A manual solution would be to edit all pages and make the links point to the published variant of the pages. However this is not only a cumbersome and error prone task, but also the users are used to the "automatic" link conversion that made links in the published variant point to published pages and are wont to continue setting links to pages in the draft space, expecting them to point to the "right place" after publishing. The fact that now titles are used throughout in the navigation tree, and the titles of the draft and published variant are usually the same and thus indistinguishable complicates the problem even more. To fix this I could write a separate extension that listens to Publish events send from the Workflow extension, and which converts the links in the published variant before it gets saved. However I remember that I once experienced strange issues where the events were sometimes not send to the event listener in question, probably due some class loader issues or the like. (I only experienced these problems in a production instance and was not able to hunt them down in a development instance.) Also I cannot think of a use case where users want to link from a published variant back into the draft space (except for pointing to the draft version of the page itself, which is provided by the panel, however.) Thus I would like to implement the link transformation in the extension itself. If a link in a page points to a page in the draft space of that workflow, I would change that link in the published variant to point to the corresponding published variant of the link target. I could add a checkbox to the workflow class so people can switch of that link transformation if they do not want it. What do you think? Are there any objections to implementing such a feature? Or do you have different ideas how to solve the problem? Best Regards Clemens

6 years, 9 months

[xwiki-devs] [XWiki Day] BFD#159

by Alex Cotiugă

Hello devs, This Thursday is BFD#159, the last one for this year: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -12 bugs over 120 days (4 months), i.e. we need to close 12 bugs to have created bugs # = closed bugs # * -56 bugs over 365 days (1 year) * -53 bugs over 500 days (between 1 and 2 years) * -237 bugs over 1600 days (4.3 years) * -684 bugs since the beginning of XWiki See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#159 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13934 Happy Bug Fixing Day, Alex

6 years, 9 months

[xwiki-devs] Next version for 9.x cycle

by Vincent Massol

Hi devs, We need to decide what’s our next version for 9.x. Since 9.11 is supposed to be the last release (actually 9.10 was even supposed to be the last one according to http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices… we might need to change that). We still have some stuff to stabilize: notifications, shortcuts, etc. So I’m proposing that the next version be 9.11.1 and not 9.12 to keep the strategy of 12 main releases per year, and to start stabilizing the 9.x cycle. WDYT? Thanks -Vincent

6 years, 9 months

[xwiki-devs] [ANN] XWiki 9.11 released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 9.11. This release brings some final touches to the notifications module by improving the look and feel of the notification center and the notification emails. Some optimizations have also been made in order to speed up the loading time of the notifications tray. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.11 Thanks for your support -The XWiki dev team

6 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs December 2017