xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Proposal] Get rid of sonar.xwiki.org?

by Vincent Massol

Hi devs, Context: * I lost the config on ci.xwiki.org to push maven results to sonar.xwiki.org. I can find them back for sure but will take me a bit of time. * We don’t use sonar.xwiki.org that much * We now have https://sonarcloud.io/organizations/xwiki/projects to which we can push results from our builds * https://sonarcloud.io/organizations/xwiki/projects is always up to date in term of sonar version and we don’t need to maintain it So my proposal is to decommission sonar.xwiki.org and to configure https://sonarcloud.io/organizations/xwiki/projects the way we want (I already did that a bit but we can tune it more) and modify our maven build to push to it. WDYT? Thanks -Vincent

5 years, 11 months

[xwiki-devs] [Discussion] Coding practice for location of internal package name

by Vincent Massol

Hi devs, On Matrix/IRC, I’ve posted the following: " * Guillaume Delhumeau: BTW your naming is strange for the internal package * for ex: package org.xwiki.notifications.preferences.internal.email; * normally we put internal just after the main package part * ie. * org.xwiki.notifications.internal.* * and org.xwiki.notifications.* for public classes * see http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/JavaCodeStyle/#HPac… * General rule is org.xwiki.(module name).internal. * I see thomas has done the same “error" for org.xwiki.job.handler.internal and org.xwiki.job.handler.internal.question . So maybe there's something to discuss/change * I guess we have a mix of both now so we should discuss it and adjust our rules if need be “ So I think we don’t have all the same rules/understanding of the definition at http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/JavaCodeStyle/#HPac… I’d like to discuss with you to see what you prefer and adjust our rules so that it matches what we do in practice. Any take in this? Thanks -Vincent

5 years, 11 months

[xwiki-devs] [ANN] XWiki 10.11 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 10.11. This version is mostly a stabilization release for the 10.x end of cycle. We've added a way to rapidly empty the wiki's recycle bin, that contains all the deleted pages. We've also polished the asynchronous execution and caching of panels added in the previous version, that makes the panels render faster. Plus we added many other improvements and bugfixes. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.11 Thanks for your support -The XWiki dev team

5 years, 12 months

[xwiki-devs] [Brainstorming] Finish refactoring for xwiki configuration directories

by Vincent Massol

Hi devs, Context ====== Clemens fixed a bug at https://jira.xwiki.org/browse/XWIKI-15163 and while doing so inroduced a new system property to override the location of the xwiki.properties file. I commented at https://jira.xwiki.org/browse/XWIKI-15163?focusedCommentId=98075&page=com.a… Even though it’s not necessary to introduce a new system property just for the need of this test (it’s easy to refactor the code to not need this IMO), it raises the question of what we want to do to make the configuration simpler in XWiki (simpler config, simpler upgrades, etc). History ====== We discussed this a few times in the past: * March 2010: http://markmail.org/message/6cvm5hocvtbqtgp6 * June 2012: https://markmail.org/message/3aq2bjrb6a2ip2ri Note that the June 2012 proposal was agreed. Globally this is what we implemented since the June 2012 proposal: * XCOMMONS-187: The Permanent Data directory resolver should support System Property "xwiki.data.dir". More specifically the code is here: https://github.com/xwiki/xwiki-commons/blob/55569d3466dc0ea36f6964474973f7a… * XWIKI-13867: Search xwiki.cfg in /etc/xwiki/ first. Code is here: https://github.com/xwiki/xwiki-platform/blob/973d4e9c6ad02dbb31d94fe96df9c1… * XWIKI-13868: Search xwiki.properties in /etc/xwiki/ first. Code is here: https://github.com/xwiki/xwiki-platform/blob/93f02215783ac0f4030fe3062cac4d… I’d like to note that I don’t remember discussions/proposals for XWIKI-13867/XWIKI-13868 and I commented on http://jira.xwiki.org/browse/XWIKI-13867 and didn’t get any response from my various comments. Current behavior ============= So right now the behavior is the following on config files (I’m excluding the recent change of Clements, see below in actions): * If xwiki.cfg exists under the. "java:comp/env” JNDI key, then it’s used * If not found, then search for it in /etc/xwiki/xwiki.cfg * If not found, then default to WEB-INF/xwiki.cfg * If /etc/xwiki.xwiki.properties exist then it’s used * if not found, search in WEB-INF/xwiki.properties (as a ServletContext resource) * If not found, then default to an empty configuration Discussion/Proposal ================ * I think we should ask Clemens to rollback the introduction of the xwiki.properties.default.dir system property and to just make the test work without introducing any system property. I can help Clemens do that. * I propose that instead we continue implementing the June 2012 proposal defined at https://markmail.org/message/3aq2bjrb6a2ip2ri and introduce the xwiki.config.dir system property. * Right now I don’t like the solution introduced by /etc/xwiki/* because they don’t allow supporting several instances of XWiki on the same machine. However, the introduction of xwiki.config.dir system property would fix it. * We could also introduce the user home dir location as a location where xwiki config files would be looked for. * We also need to generalize the config files to hibernate.cfg.xml and clustering config files (jgroup files), and logback. See https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Backup#HConfi… WDYT? Thanks -Vincent PS: Sorry for the long mail, I had to do a lot of archeology to research this… Took me a while ;)

5 years, 12 months

[xwiki-devs] [XWiki Day] BFD#202

by Oana-Lavinia Florean

Hello devs, This Thursday is BFD#202: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -42 bugs over 120 days (4 months), i.e. we need to close 42 bugs to have created bugs == closed bugs * -132 bugs over 365 days (1 year) * -151 bugs over 500 days (between 1 and 2 years) * -360 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#202 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14350 Good luck at fixing bugs, Lavinia

6 years

[xwiki-devs] [ANN] XWiki 10.8.3 released

by Clément Aubin

The XWiki development team is proud to announce the availability of XWiki 10.8.3. This is a bugfix release that covers important issues that we have discovered since 10.8.2 has been released. Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.8.3 Thanks for your support -The XWiki dev team

6 years

[xwiki-devs] [ANN] XWiki 10.11-rc-1 released

by Ecaterina Moraru (Valica)

The XWiki development team is proud to announce the availability of XWiki 10.11-rc-1. In this version we've added a way to rapidly empty the wiki's recycle bin, that contains all the deleted pages. We've also polished the asynchronous execution and caching of panels added in the previous version, that makes the panels render faster. Plus we added many other improvements and bugfixes. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.11RC1 Thanks for your support -The XWiki dev team

6 years

[xwiki-devs] GitLab extension repository and issue tracker

by Stéphane Laurière

Hi devs, I'd be interested in reporting some issues and contributing some fixes related to the GitLab extension. I noticed that its main repository is currently at <https://git.xwikisas.com/ludovic/application-gitlab>, which is not in line with the usual practice consisting in storing extensions in xwiki-contrib on GitHub. Has anyone any objection about moving the repository to GitHub and to create a JIRA project for it – say "GITLAB"? Cheers Stéphane -- Stéphane Laurière XWiki www.xwiki.com

6 years

[xwiki-devs] [XWiki Day] BFD#201

by Oana-Lavinia Florean

Hello devs, This Thursday is BFD#201: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -45 bugs over 120 days (4 months), i.e. we need to close 45 bugs to have created bugs == closed bugs * -140 bugs over 365 days (1 year) * -156 bugs over 500 days (between 1 and 2 years) * -371 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#201 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14349 Good luck at fixing bugs, Lavinia

6 years

[xwiki-devs] [ANN] Definition of Cycle Themes for XS from XWiki SAS

by Vincent Massol

Hi devs, Even though it’s up to every committer (and the companies behind them) to decide what they want to work on during each release and thus during each Cycle (see https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractice…), I’m posting this message below to be fully transparent. It corresponds to a commitment from XWiki SAS’s on how they’d like to treat Cycles from now on. XWiki SAS has decided internally to define better what a "Cycle Theme” means. The idea is for XWiki SAS to help plan roadmaps and cycles better (and be meaningful since right now a Theme doesn’t mean much), and we have an upcoming 11.x cycle coming soon. So here’s the proposal: Exec summary ============ * XWiki committers who are working for XWiki SAS will make sure that in each release of the Cycle there’s at least one roadmap item related to the Cycle Theme. * Of course XWiki committers not working for XWiki SAS can work on whatever they want during a Cycle :) Details ====== * Definition: "Having a Theme for a Cycle means that in each roadmap version for the Cycle there’s at least one item related to the Theme." * A Cycle can have one or more Themes with an ordering of Themes. When there's more than 1 Theme, an ordering of the Themes needs to be defined (main Theme, sub Theme, etc). For ex if “Usability (1st) + Security&Privacy (2nd)” are selected then there could be for example 2 items related to usability and 1 item for Security & Privacy per version. * However, seen the XWiki SAS current workforce and to leave margins for unplanned items, it was suggested to restrict to only 1 Theme in a Cycle FTM (XWiki SAS has currently 3 to 3.5 FTEs working on XWiki Standard). It could be possible to go to 2 themes but then it might be hard to enforce it so that idea was dropped for now (could be expanded next year if all goes well or if there’s more manpower). Note that it’s not because, for example, that Security would not be in the Theme that XWiki SAS wouldn't work on Security. It just means there’d be no guarantee that there’d be Security-related items in *each* roadmap. It would be decided on a per-roadmap level. * Examples of valid Themes (a theme needs to be large enough to sustain at least 11 items since we have 11 versions in a cycle): ** Usability ** Performance ** Consistency ** Accessibility ** Security & Privacy (GPRD, etc). Note: I’m putting Privacy along with Security since I’m not sure we would have enough items for Privacy as a standalone Theme. Thanks -Vincent, with my XWiki SAS hat

6 years

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs