May 2017 - xwiki-devs@xwiki.org

[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] [Proposal] Entry point for Extensions
by Vincent Massol 18 Aug '17

18 Aug '17

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

8 16

[xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?
by Thomas Mortagne 12 Jun '17

12 Jun '17

Hi devs, I'm getting closer to finish with the hard work around new platform flavor which is going to replace XE. Need to decide what user will see in the Flavor picker when installed XWiki now. As a reminder we decided that this would be a generic flavor, not tied to any specific use case (so forget about "Knwonledge Base Flavor" :)). Here is a few ideas gathered in previous mails: * "XWiki Flavor" * "Default XWiki Flavor" * "Generic XWiki Flavor" * "Base XWiki Flavor" "Generic" is probably a way too technical term. "Base" would be misleading IMO since it's not really a base flavor. Its primary goal is not to be used as a dependency (of course it's fine to have it as dependency if you just want to add pre installed extensions to the default flavor). It's a -1 for me. Frankly I would simply go for "XWiki Flavor". I know, it's not going to be the only flavor for XWiki but it's obvious when you actually see severals of those in the picker anyway and I find it nicer than "Default XWiki Flavor" which basically means the same thing since the XWiki core project does not plan to provide any other flavor. I'm also fine with "Default XWiki Favor" if others think it's a better name. WDYT ? -- Thomas Mortagne

10 22

[xwiki-devs] [Proposal][Glossary Application][Phase-1]
by Sarthak Gupta 06 Jun '17

06 Jun '17

Hi everyone, I would be working on the proposal 'Glossary Application' in the coming days. The details of the proposal can be found on the Design Page <http://design.xwiki.org/xwiki/bin/view/Proposal/GlossaryApplication> . Please tell me if something is not clear. Any suggestions are welcomed. :) I wanted to propose a UI for both the pages ('HomePage' and 'glossary page for each item'). - For the Glossary HomePage: - A search bar will be employed on the top of page, which would search a glossary page(from glossary space) if a user enters the matching words for that glossary items. A search bar will be made using HTML/CSS. - The search results (suggestions) will be displayed on the same page below the search bar along with the location of the glossary item.(considering the fact that two glossary items with the same name may exist). I saw that there is a 'Suggest Widget' for this. Hope I can make it work :P . - On clicking those links, the user will be directed to the matching glossary page. Is this UI ok? - Glossary Page of each glossary item: - It will contain two fields. - First field will be a 'String' which will contain the name of the glossary item. - Second field will be a 'text area' named "Glossary". It will contain the glossary of that item that a user will enter itself on the page, he is on. Is this UI ok? After this I will update my design page and tell you about my next steps.....! Thanks :) Sarthak Gupta [sarthakg]

2 11

[xwiki-devs] [Gsoc][Update] Red Pen Integration UI
by deshengchuan 06 Jun '17

06 Jun '17

Dear all, an update with the activities regarding the red pen integration. Red-pen side implementation: As of now I am unable to establish contact with neither the community and redpen, nor with its creator, Mr. Takahito Ito. Their community seems to be quite silent, unlike ours Hence, I will be beginning preliminary design on the UI. As of now I am planning to create the UI something like the FAQ page. Each entry on the page by the user corresponds to a particular Red-Pen Validator setting which for now would be imported into a Redpen server (As of now I will use my localhost terminal to set up the server). I am dealing with the import of the validators from the ui into the server first, before incorporating the ScriptServices that will call the dependent components which will do the proofreading. What do you think? P.S. Sorry for the absence over last week, by some bad coincidences I had 2 48-hour hackathons back to back. -- View this message in context: http://xwiki.475771.n2.nabble.com/Gsoc-Update-Red-Pen-Integration-UI-tp7604… Sent from the XWiki- Dev mailing list archive at Nabble.com.

2 6

[xwiki-devs] [GSoC] More extension repositories
by Krzysiek Płachno 01 Jun '17

01 Jun '17

GSoC Coding Part Finally starts tomorrow, so the highest time to get down to work. I created modest design page where I put summary of general idea of my project: http://design.xwiki.org/xwiki/bin/view/Proposal/Moreextensionrepositories To start coding I need: 1. A confirmed naming pattern for the extensions that I will develop. My suggestion is "..... Integration" e.g. "Pypi Integration" "Bintray Integration" Imho, the names of possible repositories are popular and verbose enough to impy that the integration is about extension repository. What do you think? 2. Repositories on https://github.com/xwiki-contrib One per each extension (i.e. external) repository: Bintray, Pypi, NPM. Is it enough if I ask for it here or should I create some official request? 3. Some space somewhere in XWiki ecosystem where I would be able to document progress and decisions made - things much more detailed and low-level that are normally presented on design pages or http://extensions.xwiki.org/xwiki/bin/view/Extension/ pages. Best, Krzysztof Płachno

2 5

[xwiki-devs] [Brainstorming] Notifications sending email
by Guillaume Delhumeau 01 Jun '17

01 Jun '17

Help me to decide! TL;DR: * I need to know if performing a query on the database for each user who want to receive an email with all the notifications, is a scalability issue (in a job context). * If it's not an issue, I can implement the "naïve" solution which requires less development. Full message: Status: * notifications are displayed on the top menu when you browse the wiki. * notifications are displayed differently for each individual user according to their preferences (filters on event type, on locations, etc...). * similar notifications are grouped together into "composite notifications". * there is only a few notifications displayed (5 by default). Objective: * send an email periodically (every hour, every day, every week) according to the user preferences with ALL events that happened during the last period of time, but still according to the user preferences. Inspiration: * the watchlist gets ALL events that happened during the last period of time * then, for each user, remove the events which the user is not interested in * Benefit: only one query to get the events from the database for all users Problems: * in the notifications, I have introduced a NotificationFilter role the make possible to inject some SQL in the query to get the events according to the user preferences. I call this "pre-filters". ** it means we generate a unique request for each individual user, so if we send a mail to 1000 users, we will have 1000 requests to the database. I wonder if it's a non-problem or a big scability issue. Because even if the whole job that send emails take ~10 minutes, it does not matter. It's not a realtime thing. For the records, NotificationFilter have "post-filters" too, that perform check on the event itself (for example checking the permissions, etc...). Alternatives: * just like the watchlist, perform a very generic query on the database to get all the events that happened during the last period of time * then for each user, use only the "post-filters" to remove events the user don't care of Problem: * it means the pre-filters that make sense in the notification use-case cannot be used for emails. Developers must be aware of this. * it requires some refactoring of the code that group similar notifications. Question: Should I go with the "naive" solution, ie for each user get all notifications and send a mail, or should I go with the "only 1 query to the database for all users" version? Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

3 10

[xwiki-devs] [Brainstorming] Make it more visible that XWiki can be deploy easily in the cloud
by Vincent Massol 31 May '17

31 May '17

Hi devs, I was checking the download page of jenkins at https://jenkins.io/download/ and I found that it’s easy to find the install/download that matches the user’s need since all options are listed on that page (deploy on azure, get a docker image, etc). On xwiki.org we have 2 buttons: Try Now + Download. I’m under the impression that the “Try Now” is not very appealing for users who want to install XWiki or get it in the cloud. I have the feeling that having a single Download button listing all options would be a better thing. In addition I also have the feeling that it would better to let the user choose the packaging before choosing the XWiki version since right now users need to choose the version before being offered the different packagings. WDYT? Thanks -Vincent

1 1