xwiki-devs February 2018

xwiki-devs@xwiki.org

17 participants
37 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] Color Themes Questions

by Ecaterina Moraru (Valica)

Hi devs, I need your input on some questions: 1. (Important) Where to commit Color Themes? 2. Where do we move old / deprecated Color Themes? 3. What should a Flamingo Theme contain? --- 1. Where to commit Color Themes? We have a running vote for a new default Color Theme. So where should this theme be committed? When considering this question think about the default theme, but also to the other Color Themes variations that won't be voted as a default. A. Platform ( https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwi… ) PRO: Being default makes sense to be committed in Platform and to not have a dependency towards a Contrib extension. CON: It will depends on an 10.x XWiki version. The themes could be used for any XWiki > 6.2. Having them outside Platform would allow installation also on older versions. CON: Slow release process for outside contributions CON: Grouped: in the current implementation they come as a package, you cannot install an individual module in a separate Flavor. B. Grouped on Contrib but as individual modules (example https://github.com/xwiki-contrib/color-themes/tree/master/color-theme-icebe… ) CON: Grouped versioning and release process. Each theme could have its own component on JIRA. PRO: Medium contributions: The Maven / JIRA / module setup is done only in the beginning, but still there are technical knowledge to be known how to contribute a theme. PRO: XWiki version independent - can be installed on older instances C. Individual on Contrib (example https://github.com/xwiki-contrib/color-theme-iceberg) PRO/CON: Independent versioning and release process. Still we will be spammed with JIRA projects for each theme. CON: Slow contributions since you need to know how to create Maven modules, provide JIRA components for each theme, release on Nexus, always ask for a repo, etc. D. Individual as XARs on e.x.o PRO: Easy / rapid contributions: you just need to provide a XAR PRO: Platform version independent CON: Cannot be referenced as a dependency from a .pom CON: No blaming or versioning of sources --- IMO the default theme should be committed in Platform (A), but all the other proposals should be in Contrib either grouped (B) or individual (C). I prefer version B (grouped on Contrib) since the themes are very similar in concept and for me it doesn't justify all the independent projects on JIRA, etc. It would be similar to what I did for Icon Themes, see https://github.com/xwiki-contrib/icon-themes Other notes: 1.1 The themes from Platform that were not default, should be made as extensions. This is the case for Garder, Kitty, Marina. 1.2 xwiki-platform-flamingo-theme-bootswatch https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwi… should be put in Contrib, as extensions, since they don't relate to XWiki. 1.3 Keeping just the default in Platform is also good for Flavors. Not all themes work for all Flavors. Each Flavor would add the dependency they want. Still this means more work in selecting these themes. --- 2. Where do we move old / deprecated Color Themes? This question applies for old Color Themes. For example when we retired Colibri, we moved all the themes in the Attic https://github.com/xwiki-attic/skin-colibri/tree/master/xwiki-platform-colo… even though those themes still worked (since we made them backwards compatible). Also the majority of themes on e.x.o are as XARs. How will we deprecate those? Also how do we mark themes that are not good looking anymore? Also this point is very subjective. I guess the answer to this question depends on what were we vote to commit the Color Themes. --- 3. What should a Flamingo Theme contain? (difference between Skin and CT) The Colibri Color Themes contained just colors. Now with the Flamingo Themes's Advanced section you could easily remove the need to have a Skin and add there also CSS rules, etc. The Bootswatch (xwiki-platform-flamingo-theme-bootswatch) themes are a very bad example, since they change quite a lot of styling and not just variables. I just want to enforce that default themes and especially themes that are provided by XWiki Development Theme should contain only variables. If there are things we need to override we should fix them first in the Skin, not just abuse the "Advanced" section capabilities and power. This is important since the changes done in the Skin apply for all the Themes. You don't need to duplicate the "hack" for all the themes. --- Let me know what you think. Thanks, Caty

6 years, 8 months

[xwiki-devs] [Usability] Bulk actions for attachments

by Ecaterina Moraru (Valica)

Hi devs, Here is a proposal for improving the drag&drop area for attachments and having bulk actions in order to rapidly delete or download multiple attachments: http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaBulkAttachments Thanks, Caty

6 years, 8 months

[xwiki-devs] [VOTE] Refresh the default Color Theme for XWiki 10.x

by Ecaterina Moraru (Valica)

Hi devs, As part of the 10.1 roadmap there was an investigation in order to refresh the UI for XWiki Standard 10.x in order to differentiate it from the older versions. Here is the detailed proposal with more screenshots: http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemes10x/ I've also run a community vote at https://forum.xwiki.org/t/refresh-the-default-color-theme-for-xwiki-10-x/26… in order to see the general preference. As committers, please state your vote also in this mail thread, so that I can count the votes properly and with the correct weight to them. Let me know if you have other proposals or questions. Thanks, Caty

6 years, 8 months

[xwiki-devs] [ANN] XWiki 9.11.3 released

by Guillaume Delhumeau

The XWiki development team is proud to announce the availability of XWiki 9.11.3. This is a bugfix release that covers important issues that we have discovered since 9.11.2 has been released, but it also disable the Watchlist and enable all Notification features by default 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.11.3/ Thanks for your support -The XWiki dev team

6 years, 8 months

[xwiki-devs] [ANN] XWiki 10.1 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 10.1. Starting with this release the Watchlist Application has been disabled and fully replaced by the Notifications Application. We continue to add new improvements to Notifications (filters, preferences, etc.) so make sure to check them out. 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/10.1 Thanks for your support -The XWiki dev team

6 years, 8 months

[xwiki-devs] Weird issue in security cache

by ktc

Hi XWiki devs, We ran into a weird issue on XWiki security cache. Our entire security cache is purged every 4 hours. Some background about our setup: We retrieve users’ group membership from LDAP We set a 4 hour expiration time on the cache(as below) because LDAP records may update at any time. <local-cache name="platform.security.authorization.cache"> <eviction max-entries="50000" strategy="LRU"/> <-- 4 hours --> <expiration lifespan="14400000"/> </local-cache> To our understanding, each cache entry should have its own timer which expires after 4 hours. But what we observe from JMX dashboard is that the entire security cache is being purged every 4 hours. Security cache JMX diagram: <http://xwiki.475771.n2.nabble.com/file/t396587/Security_Cache.png> Our user group has similar issue but purge irregularly: <http://xwiki.475771.n2.nabble.com/file/t396587/Group_Cache.png> This problem is cause big performance issue in our system. We can’t figure out the root case. Any pointer will be highly appreciated. -- Sent from: http://xwiki.475771.n2.nabble.com/XWiki-Dev-f475773.html

6 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2018