xwiki-devs November 2017

xwiki-devs@xwiki.org

9 participants
16 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, 1 month

[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, 6 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, 4 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, 6 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, 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, 10 months

[xwiki-devs] [ANN] XWiki 9.10.1 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 9.10.1. This is a bug fix release that bring corrections for important issues we have discovered since 9.10 has been released. 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.10.1 Thanks for your support -The XWiki dev team

6 years, 11 months

[xwiki-devs] [Proposal] Roadmap for XWiki 9.11

by Vincent Massol

Hi devs, We’ve just released XWiki 9.10. Let’s now define what we’ll do till the end of the year, i.e. for XWiki 9.11. The proposal is to have 9.11 be mostly a stabilization release. Here’s a proposal: * Finish FS-based attachments but don’t turn it on by default. It’ll be turned on in XWiki 10.0. Thomas already started on this in XWiki 9.10. - Thomas * Protect edition of pages coming from Extensions, in order to try improving upgrades. - Thomas * Polishing of Notifications and performance check/improvemnt (It's very important to disable it and recheck the perf report to compare with 8.4.5 to see if the problem comes from notifs for ex). - Guillaume * Generally, bug fixes/stabilization - All Dates: * 9.11RC1: 11 Dec * 9.11Final: 18 Dec (as a target but could go till end of the year) Note: * Knowing that Guillaume won’t have much during this period, it’s likely that Notifications won’t be polished enough to be marked as production level ready in 9.11 and we’ll probably need a 9.12 or 9.11.1 release in January for that. WDYT? Anything else someone would like to do? As usual please update http://www.xwiki.org/xwiki/bin/view/Roadmaps/ with the detailed list of JIRA tasks for each topic. Thanks -Vincent

6 years, 11 months

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

by Alex Cotiugă

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

6 years, 11 months

[xwiki-devs] [ANN] XWiki 9.10 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 9.10. This is mostly a release focusing on improving the new Notifications feature, in order to make it as polished and usable as possible before the end of the year (i.e. before the end of the Cycle and before we elect a new LTS release). It also contains several bug fixes. 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.10 Thanks for your support -The XWiki dev team

6 years, 12 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs November 2017