xwiki-devs January 2017

xwiki-devs@xwiki.org

17 participants
37 discussions

[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] Entry point for Extensions

by Vincent Massol

Hi devs, Problem ======= We have 2 issues right now when installing an extension in XWiki: 1) It’s not clear where is the entry point of that extension. - Example1: an app that is only for admins and only has a ConfigurableClass - Example2: an app that provides a macro and doesn’t have a UI 2) Even when an extension registers itself in the Applications Panel, the user still need to refresh the page or navigate away to see it. Proposal ======== * Introduce the concept of Entry point (a.k.a home page) in Extension metadata * Have the EM UI display the extension’s entry point (when there’s one) after having installed the extension so that the user can click on it and be taken to the home page of the extension. This would make extensions more discoverable IMO. Implementation Details ================== * Some maven extension metadata properties in pom.xml * A format to represent an entry point. It shouldn’t be a full URL since that needs to be computed at runtime. Basically it should contain: ** The document reference ** The action to use (view, admin, etc) - optional, should default to “view" ** The query string to use - optional, should default to an empty query string This corresponds to the notion of ResourceReference (EntityResourceReference to be precise). However we don’t have any textual representation of it ATM. WDYT? Good idea? Bad idea? Thanks -Vincent

7 years, 3 months

[xwiki-devs] Edit Modes vs. Editors

by Marius Dumitru Florea

Hi devs, While working on adding extension points to support the replacement of the current WYSIWYG editor I came to the conclusion that we need to make a clear distinction between Edit Modes and Editors. An Edit Mode is basically an HTML *form* that allows you to edit some data that is associated with an XWiki document. There can be for instance an edit mode to edit the document title and content, another edit mode to edit the document objects, another one to edit the document access rights, and so on. Ideally, XWiki extensions should be able to provide new edit modes. The current place where we expose the Edit Modes is the Edit Menu. Class, Objects, Access Rights, Inline Form are well defined edit modes. Before we talk about the Wiki and WYSIWYG "edit modes" let's define what an editor is. An Editor is basically a form *field*. Most of the time it is an enhanced form field, a widget, that allows you to edit a single document field. The editor obviously depends on the field type. There can be a date editor (known as date picker), a plain text editor, a rich text editor, and so on. Ideally, XWiki extensions should be able to provide new editors for specific data types. For instance an extension could replace the date picker. Another one could replace the rich text editor. The relation between Edit Modes and Editors is many to many. An Edit Mode can use multiple editors and an Editor can be used by multiple Edit Modes. For instance the rich text editor can be used in the "Content" edit mode (for document content) but also in the Inline Form edit mode, for TextArea object properties. If we agree with this distinction then I think XWiki should have separate extension points for Edit Modes vs. Editors. What does this mean for the CKEditor integration? Well, CKEditor is an editor.. so it doesn't make sense to have a "CKEditor" edit mode. CKEditor can be used to edit the document content as well as the TextArea object properties that contain wiki syntax. So there should be no "CKEditor" entry in the Edit Menu. Otherwise we need to add "Inline Form - CKEditor" also, and so on for each Edit Mode that can use the CKEditor. So I think we should go in the following direction: * Replace Wiki and WYSIWYG entries from the Edit menu with a single Entry that will represent the Edit Mode for editing the document title, content and syntax. I'm not yet sure what name should we use for this Edit Mode. Let's call it "Content" for now. * The default edit action (for simple users) will ** open the Inline Form edit mode if the document has a sheet associated ** open the "Content" edit mode otherwise * The "Content" edit mode will use the Editor configured in the User Profile, falling-back on the wiki preferences * The Inline Form edit mode will use for TextArea properties the Editor specified in the property meta data, falling-back on the User Profile setting, then on the wiki preferences * We should have an administration section to configure the default Editor as wiki level (wiki preferences) We don't have to implement all this right away. I'd like to start by making the editor list from the TextArea meta data, User Profile and wiki preferences extensible, so that CKEditor can add its entry there. WDYT? Thanks, Marius

7 years, 9 months

[xwiki-devs] [ANN] First version of the XWiki docker packaging

by Vincent Massol

Hi everyone, I’ve started a first version of a XWiki docker packaging at https://github.com/xwiki-contrib/docker-xwiki and I’ve created an automated build on DockerHub at https://hub.docker.com/u/xwiki/. The goal is to provide an official packaging done by the XWiki dev team. Since I’m a recent user of Docker I’m sure I’ve made plenty of mistakes and not following some best practices, even though I’ve tried my best to do that ;) So it would be great if: * Some users could try it out and let me know how it works * Users could tell me what they’d expect in term of setup from a docker distribution. * Some Docker experts review my code and let me know what I should improve! After I receive some confirmation that it works well-enough, my goal is to document it as an official way of installing xwiki on xwiki.org. Feel free to create jiras for ideas and bugs at http://jira.xwiki.org/browse/XDOCKER. Thanks a lot! -Vincent PS: Note that I’m sure some will want a different DB, such as postgreSQL for example. That should be easy to do. Pull request accepted! :)

7 years, 9 months

[xwiki-devs] [Proposal] Create a xwiki-jenkins repo in the xwiki GitHub org

by Vincent Massol

Hi devs, I’ve started setting up GitHub organization jobs on ci.xwiki.org. One is already set up for xwiki contrib: http://ci.xwiki.org/job/XWiki%20Contrib/ What it means: * Whenever a contrib project commits a Jenkinsfile (see example: https://github.com/xwiki-contrib/syntax-markdown/blob/master/Jenkinsfile) then automatically this project gets built by jenkins * It works for all branches and is removed when branches are removed Now, I’m working on creating some shared pipeline libraries (see https://github.com/jenkinsci/workflow-cps-global-lib-plugin) so that we can avoid duplications in Jenkinsfile. So I need an SCM location for it and it seems that it cannot be in a directory of an existing repo and it needs to be in the root of a repo. Thus I’m proposing https://github.com/xwiki/xwiki-jenkins WDYT? Note: we could also use xwiki-contrib but it would be a bit weird to use that for building xwiki org repos and my plan is to move to Jenkinsfile also for repos in the xwiki GitHub org (commons, rendering, etc). Thanks -Vincent

7 years, 9 months

[xwiki-devs] [Proposal] Roadmap for XE 9.0-9.2

by Vincent Massol

Hi devs, Here’s a proposal of topics to cover for XE 9.0-9.2 (i.e. Jan-Mar 2017). This proposal is proposed by XWiki SAS and was discussed with XWiki committers who work for XWiki SAS. If you also want to propose some other items, please do so. Ofc if you have some problems or questions with the proposed roadmap let me know in reply. * Distribution Manager Command Line Upgrade (aka Unattended Upgrades) - Thomas * Polish CKEditor - Marius * Auto-ajust column size on PDF export, to get different column lengths - Guillaume * Extension manager improvements to allow cleaner upgrades (XWIKI-12705 and XWIKI-13747) - Thomas * More Ease of Use - Marius * Default product pages should not be easily deleted - Guillaume * Move from XE to KB Flavor (up to the distribution) - Thomas * In-Product Tours and Documentation - Marius * Notification System - Guillaume @Devs: if you’re assigned to some tasks above please make sure you create JIRAs for XWiki 9.0-9.2 ASAP and assign yourself. Thanks -Vincent

7 years, 9 months

[xwiki-devs] [ANN] XWiki 9.0 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 9.0. This release marks the start of the 9.x cycle and features mostly developer and admin feature improvements. The most notable ones are the improved handling of big attachments, filesystem Recycle Bin and CK Editor improvements. 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.0 Thanks for your support -The XWiki dev team

7 years, 9 months

[xwiki-devs] [XWiki Day] Test Day #1

by Thomas Mortagne

Hi devs, Since nobody really answered the proposal until very late last week here it is: The idea today is to do a Test Day with priority to fixing long standing flickering (integration mostly) tests. You can find known flickering tests on http://jira.xwiki.org/issues/?filter=14240. The goal is to really fix them, not just add some random wait here and there ;) If you are really not confident with the area around those specific flickering tests here are some other ideas for this kind of Day: * obviously add more tests and increase the code coverage * move tests from enterprise to platform. Needed for the platform flavor and removal of XE * update jacoco covering setup (we often forget to increase it when adding more tests) * move more tests from JMock to Mockito * work on new test setups and tools: ** improve docker containers for packaging XWiki (possibly several for multiple DBs and Servlet containers). ** work on spreading Jenkins platform job into one job per maven module so that build can be spread on various agents (groovy scripting) ** Research/Use Jenkins 2 Pipeline plugin with the new DSL and commit the jenkinsfile in SCM ** Test platform to run contrib extension tests on various versions of XWiki automatically * Speedup existing tests (research xwiki startup time, remove unnecessary modules, etc) When what you fix can be linked to an issue, tag it with "testday" (same idea as "bugfixingday" when doing BFD). If not then answer to this mail to explain what you did. Good Test Day ! -- Thomas Mortagne

7 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 January 2017