xwiki-devs June 2017

xwiki-devs@xwiki.org

20 participants
42 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, 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] 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, 4 months

[xwiki-devs] [GSOC Update 3] RedPen Integration

by deshengchuan

Hi all! This is the third update regarding the progress of the Redpen integration project. Some of the info can also be accessed in the design page over here: <http://design.xwiki.org/xwiki/bin/view/Proposal/RedPenIntegration> I have created a UI on XWiki. The two main parts are such: First, the application homepage will allow users to key in possible spelling and expression errors, and their recommended corrections. I have not started on building the backend in Java to process this database yet, but I'll start on it within the next couple of weeks. Second, there is a setting page within the global administration wiki that allows the user to key in basic settings parameters e.g. setting maximum sentence length. The functionality is still restricted to validating a wiki page on document save, but I will be implementing the function to run redpen validation as a Job next, right after i finish fixing and stabilising some issues within the code. Any comments? -- View this message in context: http://xwiki.475771.n2.nabble.com/GSOC-Update-3-RedPen-Integration-tp760425… Sent from the XWiki- Dev mailing list archive at Nabble.com.

7 years, 5 months

[xwiki-devs] [ANN] XWiki 9.5.1 released

by Thomas Mortagne

The XWiki development team is not so proud to announce the availability of XWiki 9.5.1. This version fix important bugs found in 9.5: broken flavor picker in the Distribution Wizard, broken sub wiki template creation and missing extensions notifications in the profile. 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.5.1 Thanks for your support -The XWiki dev team

7 years, 5 months

[xwiki-devs] Release of first Milestone of [DokuWiki Importer Extension]

by Shubham Jain

Greetings everyone! I’m really excited to announce the First Milestone version of the DokuWiki importer extension! Available in the Extension store: http://extensions.xwiki.org/xwiki/bin/view/Extension/DokuWiki/Text/ Notes: This version can recreate the DokuWiki pages and spaces in XWiki. Milestone 2 is expected to have a syntax parser for importing the page content. (release next month). Requires the 'Filter Streams Converter Application’. Requires the ‘data’ folder of the DokuWiki instance packaged as a TGZ, and Voila! Would love to know your thoughts/reviews! :) Thanks! Shubham Jain (slayerjain)

7 years, 5 months

[xwiki-devs] [Proposal] Roadmap for XWiki 9.6-9.7

by Vincent Massol

Hi devs, Here’s a proposal for the new roadmap (for 2 months: 9.6 and 9.7). Note that it’s summer and several will be on holidays. Dates ===== * 9.6: July * 9.6RC1: 12th July (2w + 2 days) * 9.6Final: 20th of July but we need to start releasing on 17th to be sure we're done before the XWiki SAS seminar (it starts on the 21st till the 28th and during this period the committers from XWiki SAS won’t be very active! :)) * 9.7: August * 9.7RC1: 21st of August (3w) * 9.7Final: 28th of August Topics to tackle ============ * PDF Export - we need to be able to export multiple pages into one pdf file, with no errors and the best rendering possible - Vincent? * Livetable improvements - Who: Pierre + 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 * Administration: Default values - Marius? ** XWIKI-14157 Display the default and inherited values in the Administration ** XWIKI-9663 Show default value for date format in administration * Save button more visible. XWIKI-14162 Position Save buttons on a fixed-bottom area. - Pierre * Notifications - Continue work - Who: Guillaume + Clement ** Replace Watchlist (missing: realtime notifications, RSS feed, Watch this page/space/wiki) ** Replace Activity Stream ** Easy to add notifications from contrib apps ** Add notifications for the Product-team supported apps (see https://products.xwikisas.com/xwiki/bin/view/Applications/) * Get rid of old WYSIWYG - Marius? * Be able to remove help, tour, blog extensions - Thomas? * Improve XWiki Upgrades ** Display a notification when there’s a newer version available - ? ** Warnings when editing extension pages (same as for delete) - https://jira.xwiki.org/browse/XWIKI-14377 - ? If time permits =========== * Add support for Maven `<exclusions>` in Extension Manager * Performance work ** Finish stuff to make filesystem attachment/history content the default (automatic migration, broken deleted attachments UI, etc.) ** Store the job status in separated files (XCOMMONS-1121) ** Live storage of the job log instead of at the end of the job execution(XCOMMONS-764) ** Async macros, panels, ui extensions, etc. ** ... * Tour improvements ** add UI to use of `reflex` atrribute (TOUR-57) WDYT? Thanks -Vincent

7 years, 5 months

[xwiki-devs] Glossary Application [GSoC][Update]

by Sarthak Gupta

Hi all, This mail is regarding the status of the project Glossary Application. I have developed the basic UI for the application which enables a user to add a glossary application and also search the already existing glossary item in the glossary space. The UI is still not very user-friendly as I had decided to finish off the leftover designing part after adding more features and just before the release of the first version. The next part of the project was "adding transformations". I have written the code for basic transformation but still facing some errors in it. Hope the errors may be rectified after some code review. The task that will be left before releasing the first basic version will be "the ability to add glossary items from the wiki pages by selecting the words on Wiki pages". More details on http://design.xwiki.org/xwiki/bin/view/Proposal/GlossaryApplication <http://design.xwiki.org/xwiki/bin/view/Proposal/GlossaryApplication>. Also, tests are to be written for each fo the above. Rest of the features which are to be added (See Design Page) will be implemented after the release of the first version. :) Thanks Sarthak Gupta

7 years, 5 months

[xwiki-devs] [ANN] XWiki 9.5 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 9.5. Lots of usability improvements: improved Livetable filtering (Date filters, Multilist filters, DBList filters), Page Templates can now be auto-selected based on the current location, simplified way of adding a logo to a Color Theme and a lot more. In addition, the new Notifications feature has been worked on too: grouping of related notifications, ability to send emails, configuration of locations and sending diffs in emails. Last but not least: XWiki Enterprise is dead! We now have a new XWiki distribution that asks you at startup what Flavor you'd like to use for your wiki, and we're providing a default Flavor called the Standard Flavor (the closest to the previous XWiki Enterprise distribution). In the future there should be more Flavors offered. 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.5 Thanks for your support -The XWiki dev team

7 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2017