January 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] 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] [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

[xwiki-devs] BaseObject ID collisions
by Marc Sladek 11 Feb '18

11 Feb '18

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

4 11

[xwiki-devs] [Proposal] Roadmap for XWiki 10.1
by Vincent Massol 05 Feb '18

05 Feb '18

Hi devs, Here’s a proposed roadmap discussed with XWiki SAS devs (Thomas, Guillaume, Caty) who are available to work on 10.1. Scope ===== * Finish moving to FS-based attachments by default (it was planned for 10.0 already) - Assignee: Thomas * Finish polishing/tuning/fixing Notifications and remove watchlist - Assigne: Guillaume ** Idea: enable mails by default when notifs are enabled. * Prevent accidental move/renames - http://jira.xwiki.org/browse/XWIKI-14591 - Assignee: Thomas * Start discussions to agree about usability proposals listed at http://design.xwiki.org/xwiki/bin/view/Proposal/Usability/Tasks5/Prioritiza… so that the first ones can be done during 10.2 and 10.3 - Assignee: Caty * Skin refresh investigation (including Bootstrap 4) - Assignee: Caty Dates: ===== * 10.1RC1: 19 Jan 2018 * 10.1Final: 26 Jan 2018 Let me know if you have any remarks/issues or if you wish to contribute something extra to this roadmap. Thanks -Vincent

2 3

[xwiki-devs] [ANN] XWiki 9.11.2 released
by Thomas Mortagne 31 Jan '18

31 Jan '18

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

2 2

[xwiki-devs] KnockoutJs is a great library
by Guillaume Delhumeau 31 Jan '18

31 Jan '18

Hi developers, We have never really decided what we will do with javascript frameworks in the future. Angular was a good candidate at some point, and we have even used it in the File Manager application. But then we have been very disappointed when we discovered the new versions of Angular were not retro-compatible. It may have been fixed since then, but I have not really followed the news about it. An other disadvantage of AngularJS is that it does too much. For example, they have a custom component system with a kind of dependencies injections. But we already can do that with RequireJS, for which it is the job. I have already started to split my JavaScript's code in several components thanks to RequireJS, and it works well. I think it's good to continue with RequireJS. It is currently our go-to library when we need to use jQuery, or even... Angular. I have worked a lot on a new version of the Nested Pages Migrator last year. The new version has never been released, because of blocking bugs on the XWiki Platform's core-side. But I now have some experience with the library I used: KnockoutJS. It's a very simple library that does only one job and does it well: two-way data-bindings. It plays well with RequireJS and it does not re-invent its own component mechanism. The HTML code is not polluted by non-valid tags (instead it uses "data-" properties and special HTML comments). The documentation is extremely clear, and tutorials are great. It's not the most popular library out there, but it's stable and still alive. The trends are changing so quickly in the JS world (React was the star not so long ago, but now it is hated because of a license change...), but Knockout is still there. If the project dies, I think it will be easier to replace it with an other simple library than a big "framework". This is not a proposal or a vote, but only a feedback about this library. You can test it there: http://knockoutjs.com/ Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

2 2

[xwiki-devs] [ANN] XWiki 8.4.6 released
by Alex Cotiugă 30 Jan '18

30 Jan '18

The XWiki development team is proud to announce the availability of XWiki 8.4.6. This is a bugfix release that covers important issues that we have discovered since 8.4.5 has been released. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/8.4.6/ <http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/9.11.1> Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [ANN] XWiki 10.0 released
by Guillaume Delhumeau 29 Jan '18

29 Jan '18

The XWiki development team is proud to announce the availability of XWiki 10.0. This release introduces the new 10.x cycle, corresponding to the 2018 year. It brings a lot of bug fixings to start the year on good basis. It is also the first release which include the result of the teenager learning program called Google Code-In <https://codein.withgoogle.com/tasks/?sp-organization=6299430183501824>, allowing young people to have a first experience on software's development and sponsored by Google. You can even read a testimonial of one of the students there <https://gci17withxwikki.wordpress.com/2018/01/24/my-google-code-in-experien…> . 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/10.0/ Thanks for your support -The XWiki dev team

2 1