xwiki-devs August 2017

xwiki-devs@xwiki.org

14 participants
31 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, 3 months

[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, 7 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, 6 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, 7 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, 1 month

[xwiki-devs] [Proposal] Deprecate platform.xwiki.org and enterprise.xwiki.org

by Vincent Massol

Hi devs, Caty and I would like to work on improving xwiki.org and the first big items that we’d like to do is: * Move all content from platform.xwiki.org & enterprise.xwiki.org to xwiki.org (i.e. the main wiki) * When moving pages, use redirects * Deprecate platform.xwiki.org & enterprise.xwiki.org by adding a banner (After Header UIX) * Move all pages to 3 locations on the main wiki: Documentation.UserGuide, Documentation.DevGuide and Document.AdminGuide * We also replace “XWiki Enterprise” with “XWiki” and be as generic as possible WDYT? Thanks -Vincent

7 years, 3 months

[xwiki-devs] [Proposal] Improve translations best practices

by Clément Aubin

Hi everyone ! So, recently I have been dealing with a module that uses two kind of translation strings. - "Static" translations : the title of a block, a xHint, … the translation key itself is not meant to be changed over time. - "Dynamic" translations : things like : - mymodule.component.<componentId>.name - mymodule.component.<componentId>.description Those are translation strings that depend on a parameter (here componentId) that can be part of a list. If you want a better in-context example, check out this gist : https://gist.github.com/aubincleme/19edb249082185deedc8ec36fe354d42 Currently, we don’t have a lot of best practices regarding the translation keys (see the doc : http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTransla…), so it may b nice to think about improving them. Here are some proposals : * For translation keys used for a livetable, we could use the following : <prefix>.<liveTableId>Table.<columnName> or <prefix>.table.<columnName> if the livetable doesn’t have a specific id. * If we deal with "dynamic" translation keys, it would be nice to mark them as different from the others with an underscore (_) prefix, or a specific keyword. WDYT ? Thanks, Clément

7 years, 3 months

[xwiki-devs] [XWiki Day] ProgrammingRights-Fixing-Day #1

by Vincent Massol

Hi devs, Let’s do our first ProgrammingRights-Fixing Day. The goal is to modify pages part of XWiki Standard that require PR so that they don’t require PR anymore (for example by adding new APIs or using other APIs). Here’s a list of pages that currently require PR (there are probably more): * XWiki.DeletedDocumentsJSON * AppWithinMinutes.DynamicMessageTool * AnnotationCode.Style * XWiki.DeletedDocuments * AppWithinMinutes.LiveTableEditSheet * AppWithinMinutes.ClassEditSheet * XWiki.DeletedAttachments * Main.Activity * AnnotationCode.Script (see http://jira.xwiki.org/browse/XWIKI-10446?focusedCommentId=83579&page=com.at… ) I suggest that we each mention which page we’re handling to avoid duplicating work. Let’s try it! I have no idea what we’ll succeed in doing or not but we need to try :) Thanks -Vincent

7 years, 3 months

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

by Vincent Massol

Hi devs, Here’s a proposal for XWiki 9.8 (1 month): Dates ===== * 9.8RC1: 18th of Sep 2017 * 9.8: 25th of Sep 2017 Sure ==== Regressions (highest importance): * Put back the ability to import from office in CKEditor (as we had in the GWT editor) - Marius Some leftovers from previous roadmaps to finish: * Livetable improvements - Marius ** Implement bulk actions on livetable items ** Allow List of Users filtering also by entering first and last name, not just the user id ** Displaying a livetable list filter for a non-static list field is not scalable ** Support LiveTable text filtering on DBListclass columns * Notifications - Continue work - Guillaume ** Finish replacing the Watchlist ** Replace the Activity Stream ** Add notifications for recommended apps New: * XWIKI-14605: REST resource installed as extension is broken when upgrading/uninstalling a JAR from the same namespace or root namespace - Thomas Other: * Work on restructuring xwiki.org on several aspects - Vincent + Caty ** Remove XWiki Enterprise and mention the Standard flavor instead ** Improve the navigation by adding a navigation panel on the left and reorg pages as nested pages where it makes sense ** Small improvements to the skin to make it simpler for a website If time permits ============ * Fix the move issue: http://jira.xwiki.org/browse/XWIKI-14626 * 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 * XWIKI-14162: Save button more visible. Position Save buttons on a fixed-bottom area. (continue from Pierre's PR) * Improve XWiki Upgrades ** Display a notification when there’s a newer version available ** XWIKI-14377 Warnings when editing extension pages (same as for delete) * Multipage tour feature * Add an {{attachments}} macro * Performance work ** Finish stuff to make filesystem attachment/history content the default (automatic migration, broken deleted attachments UI, etc.) Let me know if anyone sees any issue with this and if other devs/contributors want to contribute something for 9.8! Thanks -Vincent

7 years, 3 months

[xwiki-devs] [GSOC] Release of version 1.0 of DokuWiki importer

by Shubham Jain

Greetings everyone! I’m delighted to announce the first stable public release of the Dokuwiki importer, completing my GSOC project. This importer can now: > Support all supported archives from apache compress as both File and streaming input. > Can import user data, document revision, and also attachments. > Using the syntax parser from M2, it can convert the dokuwiki syntax to xwiki/2.1 syntax strings. This can be downloaded from the extension page here: http://extensions.xwiki.org/xwiki/bin/view/Extension/DokuWiki/ <http://extensions.xwiki.org/xwiki/bin/view/Extension/DokuWiki/> Note: The syntax parser can also be used separately to parse dokuwiki syntax. Suggestions/bugs are welcome! Thanks! Shubham Jain

7 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs August 2017