xwiki-devs September 2017

xwiki-devs@xwiki.org

8 participants
17 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] [Proposal] Replace OpenJS Keyboard JS with Keypress JS for handling keyboard shoirtcuts

by Vincent Massol

Hi devs, We’re currently using http://www.openjs.com/scripts/events/keyboard_shortcuts/ but it has some limitations. Clement and I tried to find some unused combinations of keys that works on Mac and Unix and we couldn’t find any that worked with it. It also doesn’t support having combinations with several letters for example. For example we could imagine having H+H+H for turning on/off hidden documents (as a developer key sequence since it’s not a user use case). I’d like to propose using https://dmauro.github.io/Keypress/ which is under the Apache 2 license and that seems to work well on Mac and Unix and it’s very powerful. See sequence combos for example. The API look simple and nice and I don’t think it would be hard to continue support our data structure inside the “shortcuts” variable to make it work with it. WDYT? Thanks -Vincent

7 years

[xwiki-devs] [Proposal] Roadmap for XWiki 9.9 + 9.10

by Vincent Massol

Hi devs, Here’s a proposal for XWiki 9.9 + 9.10 (2 months). Dates ===== Roadmap for the coming 2 months. * 9.9RC1: 16 Oct 2017 * 9.9: 23 oct 2017 * 9.10RC1: 13 Nov 2017 * 9.10: 20 Nov 2017 Sure ==== * Notifications - Continue work - Guillaume ** Finish replacing the Watchlist ** Fix UX and improve UI - Help from Caty needed! ** Add notifications for recommended apps * XWIKI-14377 Warnings when editing extension pages (same as for delete) - Thomas (Priority) + Caty help for the UI * Fix the move issue: http://jira.xwiki.org/browse/XWIKI-14626 - Thomas (Priority) * Performance work - Thomas ** Finish stuff to make filesystem attachment/history content the default (automatic migration, broken deleted attachments UI, etc.) If time permits =========== * XWIKI-14162: Save button more visible. Position Save buttons on a fixed-bottom area. (continue from Pierre's PR) * Livetable improvements ** Implement bulk actions on livetable items * Administration: Default values ** {{jira url="https://jira.xwiki.org" style="enum"}}XWIKI-14157{{/jira}} Display the default and inherited values in the Administration ** {{jira url="https://jira.xwiki.org" style="enum"}}XWIKI-9663{{/jira}} Show default value for date format in administration * Multipage tour feature * Add an {{attachments}} macro * More perf work ** {{jira url="https://jira.xwiki.org" style="enum"}}XCOMMONS-1121{{/jira}} - Store the job status in separated files ** {{jira url="https://jira.xwiki.org" style="enum"}}XCOMMONS-764{{/jira}} - Live storage of the job log instead of at the end of the job execution ** Async macros, panels, ui extensions, etc. ** ... * Start Page API work Let me know if anyone has any comment or if some contributor/committers want to work on more stuff! :) Thanks -Vincent

7 years, 1 month

[xwiki-devs] [ANN] XWiki 9.8 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 9.8. This release introduces a new feature for the Notifications: Watched Entities. It is an experimental feature that will soon replace the Watchlist Application. To try it out and get familiar with it, you need to enable it, since it is currently disabled by default. For users, we now have more usable notification filter settings, a nice helper when you edit a "Database List" field and a feature that was missing from the CKEditor integration, which is office import. For developers, it is easier to propose an extension containing REST resources, or to customize the Flamingo LESS code. We have also exposed more database columns in the Query Module for users who don't have programming rights. The notification filters AST (Abstract Syntax Tree) proposes new types of nodes to create complex filter queries. There are also new facilities to avoid using SyntaxFactory, to make Extension Manager faster, or to have more control over some skin elements (CSS IDs and layout variables). 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.8 Thanks for your support -The XWiki dev team

7 years, 1 month

[xwiki-devs] [Proposal] Process for handling flaky tests

by Vincent Massol

Hi devs, I’d like to implement this process: * When we discover a flaky test, we create a jira issue for it and we fill a custom field to indicate in a structured manner the name of the test class and test method (e.g. using the “<class name>#<method name>” format). * When a test fails, our Jenkins pipeline script verifies if it’s listed in jira and if so, doesn’t send a mail but marks it in the UI (same as when we detect environment-related false positives). Let me know quickly if you don’t like it since I’m adding the custom field to jira as I’d like to progress on the scrjpt. Thanks -Vincent

7 years, 1 month

Re: [xwiki-devs] [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

by Ecaterina Moraru (Valica)

Hi, I finally got the time to make another iteration for these comparison pages. If anyone want to make modifications on the texts, they are available at: - http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/ - http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/XWiki-vs-Confluence/ - http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/XWiki-vs-MediaWiki/ They should look like: - Compare: http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrg2017/preview_Co… - XWiki vs. Confluence: http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrg2017/preview_Co… - XWiki vs. MediaWiki: http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrg2017/preview_Me… I'm curious to know what you think about this version in terms of layout, validate the content, maybe you have other points that we can compare the solutions on, maybe I wrote something wrong for the solutions. Let me know, Caty On Tue, May 17, 2016 at 11:17 PM, Bryn Jeffries <bryn.jeffries(a)sydney.edu.au > wrote: > Denis Gervalle said: > > > Yes, we only maintain documentation for the latest version of XWiki on > > > xwiki.org (not enough manpower to have decent doc for several versions > > > ATM). > > > > > > > However, for version 6.2.5 and later, you have a way to mitigate this > > limitation. You can install the Scripting Documentation Application on > your > > own wiki (see > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Scripting+Documenta > > tion+Application). > > Thanks, I did not know about this tool, which sounds excellent. > > > Unless you are using XWiki prior to 4.2 , using Wiki Component is > definitely > > the recommended way to writes Groovy components. Registering > > components "by hand" from a groovy script has many drawbacks not only > > the restart one, and you should avoid doing that. The best is of course > to > > write the components in Java, and install them as an extension. > > I've found the ability to write small Groovy scripts as components has > been very handy and simpler than writing full extensions in Java. For > utilities that I don't wish to make into public extensions the burden of a > small Groovy script into a proper extension seems prohibitive (although > that may just be that I haven't written one yet, and I'm just a walker at > the bottom of a hill complaining about how high it looks...). Last time I > asked there is was no simple way to install private extensions. Also, I > didn't have much luck writing a proper component in Groovy, which I > sometimes prefer to Java. > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users >

7 years, 1 month

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

by Alexandru Cotiuga

Hello devs, Today is BFD#150: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -44 bugs over 120 days (4 months), i.e. we need to close 28 bugs to have created bugs # = closed bugs # * -72 bugs over 365 days (1 year). * -60 bugs over 500 days (between 1 and 2 years) * -175 bugs over 1600 days (4.3 years) * -812 bugs since the beginning of XWiki Lately, a lot of bugs have been reported and we need to catch up. See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#150 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13917 Happy Bug Fixing Day, Alex

7 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2017