- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Proposal] Roadmap for XS 11.1 & 11.2

by Vincent Massol

Hi devs, Here’s a proposal for XS 11.1 & 11.2 (already discussed with devs from XWiki SAS). XS 11.1 - February ================= Goals: * Focus on finishing items marked important in 2018 and that couldn't be started Topics: * All: BFD (Priority on Notifications for Guillaume) * STAMP: Vincent (30%) * FASTEN: Vincent (10%) + Thomas (30%) * Simon: Finish "Browsers usually cache JS/CSS resources even if they have changed” (https://jira.xwiki.org/browse/XWIKI-6073) * Simon: Display Reference of documents to copy paste * Marius: Finish autocomplete of references in WYSIWYG Macro parameters (include/display macros, etc) * Marius: ConfigurableClass doesn't support page level configuration case * Marius: Improve the XClass picker when in object edit mode (make it like the Add Macro dialog for WYSIWYG editor) * Thomas: Finish Hibernate upgrade + Performances + Velocity 2.x upgrade Dates: * 11.1RC1: 18th of Feb 2019 * 11.1: 25th of Feb XS 11.2 - March =============== Topics: * STAMP: Vincent(30%) * FASTEN: Vincent (10%) + Thomas (30%) * All: BFD (Priority on Notifications for Guillaume) * Simon: XWIKI-1657: Allow to rename attachments. * Marius: one item from Caty's usability list to select, see https://design.xwiki.org/xwiki/bin/view/Proposal/UsabilitySelection/Usabili… * Thomas: Performances Dates: * 11.2RC1: 18th of March 2019 * 11.2: 25th of March Feedback? Thanks -Vincent

6 years, 7 months

1
1
0 0

[xwiki-devs] [VOTE] Drop support for IE11

by Ecaterina Moraru (Valica)

IE is the last browser we are supporting at a particular version, see http://dev.xwiki.org/xwiki/bin/view/Community/BrowserSupportStrategy . For all the other browsers, we are supporting just the latest release. We are supporting the latest version of Microsoft Edge since XWiki 9.9, starting from 24/Oct/17. Microsoft Edge replaced Internet Explorer as the default web browser since the release of Windows 10 (launched Jul 2015). Internet Explorer 11 is maintained on Windows 10 for compatibility purposes, but is deprecated in favor of Edge and is no longer actively developed. We discussed dropping IE11 in the past Oct 6, 2017 (see https://xwiki.markmail.org/thread/qsrkka6zfrmyxv3d), but the vote failed. Some updated statistics: -------------------------------------------------- XWiki.org's 1 year traffic (between Sep 30, 2016 - Sep 30, 2017) compared to Oct 1, 2017 - May 31, 2018: - Internet Explorer dropped from (5.84%) to (4.65%) -- from this percentage, IE 11 usage has increased from (88.43%) to (88.76%) - Edge increased from (1.56%) to (1.84%). In terms of Worldwide market share for Desktops, for the past 12 months (according to http://gs.statcounter.com/browser-market-share/desktop/ ), we have Sep, 2016 - Sep, 2017 compared to May 2017 - May 2018: - Internet Explorer dropped from 8.21% to 6.97% - Edge dropped from 4.3% to 4.15% In May 2018, Global Market Share Worldwide for All Platforms contains: - Chrome 58.09% - Safari 13.78% - UC Browser 8.16% - Firefox 5.27% - Opera 3.68% - Internet Explorer combined is at 3.08% (with IE 11 having 2.65%. IE11 in August 2017 had 3.04%) - Edge combined having 1.91% (Edge combined in August 2017 had 1.8%) - etc. -------------------------------------------------- In terms of statistics, IE11 is more used than Microsoft Edge. The only argument of dropping IE11 is that it's a browser that is deprecated for about 3 years, and it's limiting the usage of newer specifications (like CSS Flex, Grid, etc.) I'm curios about how this period of supporting both IE11 and Edge went, and if you have other examples of things you wanted to use and are not supported by IE11. Thanks, Caty

6 years, 7 months

3
4
0 0

[xwiki-devs] [Proposal] Document picker in include and display macros

by Adel Atallah

Hi devs, After discussing with Marius and Thomas, we thought it might be a good idea to do the following to have a document picker in the include and display maros: * Remove the deprecation of the document parameter (only for the include macro). * Introduce a new annotation to macro parameters to specify / override its type (different from its actual java type). The new annotation will mostly be useful for the WYSIWYG side. In our case we want to use the document parameter which is a String. The annotation will allow us to work with a DocumentReference instead which can be used to display the document picker when editing the macro in WYSIWYG mode. To be clear, here is how we would use it: @PropertyType(DocumentReference.class) public void setDocument(String document) WDYT? Thanks, Adel

6 years, 7 months

4
12
0 0

[xwiki-devs] MyXWiki.org legal information

by Ecaterina Moraru (Valica)

Hi Devs, We had an user ask about MyXWiki.org privacy agreements, see https://forum.xwiki.org/t/agreement-on-wiki-at-myxwiki-org-privacy/4241 I've added more details on MyXWiki.org homepage about: * Who is the legal entity behind MyXWiki? * What about Copyright and Intellectual Property? * What about Privacy Policy? See https://www.myxwiki.org/xwiki/bin/view/Main/ Please review it, see if you have more adjustments / details. Thanks, Caty

6 years, 7 months

3
3
0 0

[xwiki-devs] [Proposal] Change of XS Cycle strategy to account for Christmas

by Vincent Massol

Hi devs, Some devs mentioned it’s too hard to release the N.11 release since it happens around Christmas every year. Here’s a proposal: * Shorten the cycle to 11 releases instead of 12. * Release N.9 at end of Nov * Release N.10 at end of first week of Jan. Note: N.10RC1 would be released mid December (about 17th of Dec to have 3 weeks of RC). * Release N+1.0 at end of February. Start of N+1.0 work Pros: * No release during Christmas, yeah :) * More time to prepare the first LTS bugfix release, i.e. N.10.1, which can be done during the month of January. * More time for the first released of N+1 (i.e. N+1.0). This is important since that’s the release where we can do heavy refactoring and it’s not bad to get some more time. Cons: * One less release WDYT? Do you see other cons? Thanks -Vincent

6 years, 7 months

7
15
0 0

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

by Oana-Lavinia Florean

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

6 years, 7 months

1
1
0 0

[xwiki-devs] [proposal] Don't rely on depth anymore for HeadingLevelSplittingCriterion

by Simon Urli

Hi everyone, I'm working on the document splitter in order to fix the following issue: https://jira.xwiki.org/browse/XWIKI-13100 However I noticed that the current implementation of the document splitter relies on the XDOM depth. That means if an user wants to split a document with header level 1, the header blocks have to be under the root of the document, they cannot be under a GroupBlocks, or as it's the case in XWIKI-13100, under a NumberedListBlock. Moreover, currently we do not rely at all on the header block level for the splitting: if you have a header level 2 under the root and you decided to split the document with header level 1, it will be splitted since only the document depth is used. So I propose to change this behaviour and to rely on HeaderBlock header level *only* for the splitting criteria: the depth won't be used anymore. In practice I propose to keep the API of SplittingCriterion which defines the method with depth parameter, but to not rely on this parameter in the HeadingLevelSplittingCriterion implementation, that we rely on for splitting imported office document. WDYT? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

6 years, 8 months

1
0
0 0

[xwiki-devs] [ANN] XWiki 10.11.1 released

by Adel Atallah

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

6 years, 8 months

1
0
0 0

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

by Oana-Lavinia Florean

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

6 years, 8 months

1
1
0 0

[xwiki-devs] [Proposl] Improve JIRA resolution and introduce a "Solved by" resolution

by Vincent Massol

Hi devs, Right now we often use “duplicate” when we have an issue that is solved by another issue (usually a more specific one). This is not semantically correct. Proposal: * Add a new jira resolution named “Solved by” * Best practice: when using “solved by”, also use the “depends on” link WDYT? Thanks -Vincent

6 years, 8 months

7
7
0 0

[xwiki-devs] [Global Coverage] Modules to check having lost more than 3% since 2017-12

by Vincent Massol

Hi devs, Would be great if we could check these big TPC regressions since 2017 (see http://maven.xwiki.org/site/clover/20190110/XWikiReport-20171222-1835-20190…): xwiki-platform-rendering-wikimacro-api 89.2753 82.1678 -7.1075 -0.0206 xwiki-platform-icon-script 36.2068 28.9156 -7.2912 -0.0093 xwiki-platform-jodatime 36 20 -16 -0.0077 xwiki-platform-bridge 78.0612 72.1698 -5.8914 -0.0072 xwiki-platform-wiki-script 89.2405 84.1772 -5.0632 -0.0051 xwiki-platform-icon-api 100 84.1269 -15.873 -0.0029 xwiki-platform-notifications-script 80.9523 61.9047 -19.0476 -0.0025 xwiki-platform-wiki-template-default 58.5937 55.4687 -3.125 -0.0025 xwiki-platform-instance 65.625 62.5 -3.125 -0.0012 xwiki-platform-velocity-xwiki 88.2352 76.4705 -11.7647 -0.0012 xwiki-platform-rest-api 50 40 -10 -0.0009 xwiki-platform-localization-script 82.5396 79.3814 -3.1582 0.0008 xwiki-rendering-syntax-xwiki20 96.1586 92.1161 -4.0424 0.0015 xwiki-platform-refactoring-default 84.9557 81.6112 -3.3445 0.0104 I’ve listed all modules for which we lost more than 3% global TPC. Would be great if each of us take 1or 2 to analyze (and fix if it’s a real problem). Thanks -Vincent

6 years, 8 months

1
0
0 0

[xwiki-devs] [Proposal] Improve our Test Coverage strategy (TAKE 2)

by Vincent Massol

Hi devs, We started discussing a first global test coverage strategy in https://markmail.org/message/grphwta63pp5p4l7 I’d like to propose some updates and tuning now that we have a Clover Jenkins pipeline working (brainstormed with Simon): Here’s the new proposal: * We run the Clover Jenkins pipeline every night (between 11PM-8AM) * The pipeline sends an email whenever the new report has modules lowering the global TPC score compared to the baseline report (negative contribution per module) * The baseline report is the report generated just after each XS release. This means that we keep the same baseline during a XS release ** Technically it means that the pipeline will update the latest.txt file (which contains the clover report timestamp) when it notices a version change * We add a step in the Release Plan Template to have the report passing before we can release. * The RM is in charge of a release from day 1 to the release day (already the case), and is also in charge of making sure that the global coverage job failures get addressed before the release day so that we’re ready on the release day. Options: * Make it easier and only fail the pipeline job when the global TPC value is lower than the baseline (vs failing whenever a module has negative contribution) WDYT? Thanks -Vincent

6 years, 8 months

5
9
0 0

[xwiki-devs] [Proposal] Include Cycle release notes in the RN LT

by Vincent Massol

Hi devs, This is especially for Caty who created: * https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki7x/Summa… * https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki8x/Summa… * https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki9x/Summa… * https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki10x/Summ… Right now these summaries don’t appear on https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ I’m proposing to simply add a ReleaseNotes.Code.ReleaseNoteClass xobject to them so that they can appear in the RN LT, and to use the following xproperty values: * Product: XWiki * Version: 7.x, 8.x, 9.x, 10.x * Is released: true * Release Date: 31/12/<year> The alternative is more complex and involves creating a new XClass for Cycle Summaries and modifying the home page to list cycle summaries in a LT (so that it can scale). Of course we could also do a lightweight version by simply having a link on the home page to a cycle summary page listing links to individual summaries. It would be less visible but could be acceptable. However, the best and easiest is for me to add the ReleaseNotes.Code.ReleaseNoteClass xobjects to Cycle RN pages. WDYT? Thanks -Vincent

6 years, 8 months

2
6
0 0

[xwiki-devs] Hibernate upgrade

by Adel Atallah

Hi devs, As you may know, we are currently using a pretty old version of Hibernate in XWiki and we could benefit from its upgrade. The new version should bring many bug and security fixes (even though they don't all apply to our current version) along with better APIs and the possibility to integrate other tools (such as other / newer libraries or a better connection pool such as the one mentioned in [1]) Currently, I've been trying to make the following upgrades: * 3.6.9 to 4.0.1 * 4.0.1 to 4.3.11 * 4.3.11 to 5.0.12 The goal is to arrive at version 5.4.0, which is at this date the latest stable version. I chose to make the upgrade step by step to avoid having to much issues to solve at once. So far, I've made a pull request ([2]) that you can check for the 4.0.1 upgrade. Here are some of the issues that I've encounter during the upgrades: 3.6.9 to 4.0.1: * Conflicting dependencies: I had to exclude some dependencies in the pom file. * The org.hibernate.Session#connection method removal [3]: I'm either using the Session#doWork method or the Session#createSQLQuery one. * The org.hibernate.connection.ConnectionProvider interface has changed: I had to adapt the DBCPConnectionProvider class that we have, mostly to keep backward compatibility, using C3P0ConnectionProvider as a model. * The Session#getSession(EntityMode) method has been removed [4]: I have no idea how to replace that so we need to test it properly. * Some attributes in org.hibernate.cfg.Configuration have been removed: This has mostly an impact on the custom mapping injection which we need to check. 4.0.1 to 4.3.11: * A change in the hibernate schema update generation makes the update fail [5]: I had to add a property in the hibernate file but I don't think this is the best solution. 4.3.11 to 5.0.12: * The org.hibernate.cfg.Configuration has changed again removing many methods that we were using There are some other issues that I've not mentioned or discovered yet. So for me the biggest issues are: * The schema update: I think we should start using the hibernate one instead of our own (except for migration made with liquibase). * The custom mapping injection: We will need to rewrite it a bit if we want to upgrade to 5.x. The goal for now is to make the 4.0.1 upgrade work. Please let me know what you think or if you have any questions. Thanks, Adel [1] https://jira.xwiki.org/browse/XWIKI-8286?focusedCommentId=96486l#comment-96… [2] https://github.com/xwiki/xwiki-platform/pull/1012 [3] https://hibernate.atlassian.net/browse/HHH-2603 [4] https://hibernate.atlassian.net/browse/HHH-6330 [5] https://hibernate.atlassian.net/browse/HHH-8162

6 years, 8 months

2
1
0 0

[xwiki-devs] [Proposal] Roadmap for XS 11.0

by Vincent Massol

Hi devs, New year, new cycle starting! :) Here’s a proposal for XS 11.0 (already discussed with devs from XWiki SAS). The idea of XS 11.0 is double: * Finish leftovers from 10.11.x * Start important refactorings that can be dangerous XS 11.0 - January ================= Goals: * Finish important leftovers from 2018 * Do some refactoring/core changes since they may require time to stabilize Leftovers from 10.x: * Marius/Adel: Auto complete of references in WYSIWYG Macro Dialog (+ grouping feature so that users don't get both "page" and "reference" at the same time + "deprecated"/"priority" to show "page" more proeminently than "reference") * Simon: Import: make it work with new versions of Libre Office (idea: use a more recent fork of jodconverter, we identified one and check if we need to merge changes we did in our fork) * All: Fix all WCAG failing tests and more generally move to WCAG 2.1 (https://www.w3.org/TR/WCAG21/) - Rationale: usability through accessibility, current failing test reducing trust in CI * Thomas: Fix filesystem storage: https://jira.xwiki.org/browse/XWIKI-15620 New topics: * All: BFD (Priority on Notifications for Guillaume) * STAMP research project: Vincent(30%) * FASTEN research project: Vincent (20%) + Thomas (30%) * Marius: Ability to rename an AWM app * Simon: Fix caching of JS resources forcing reload when upgrading XWiki. Especially for the Navigation Panel. * Adel: Upgrade to Hibernate 5.x * Thomas: Move to Velocity 2.x Dates: * 11.0RC1: 21st of Jan 2019 * 11.0: 28th of Jan As usual: * Feedback welcome especially if you don’t think something is doable * Any other contributor/committer who want to do something for XS 11.0 is free to add more stuff here to the list * Devs: This proposal is now live on https://www.xwiki.org/xwiki/bin/view/Roadmaps/. Please edit and list (create them if need be) the individual JIRA issues needed for your tasks. Thanks -Vincent

6 years, 8 months

1
0
0 0

[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

6 years, 8 months

6
9
0 0

[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

6 years, 8 months

7
8
0 0

[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

6 years, 8 months

1
0
0 0

[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 ;)

6 years, 8 months

2
2
0 0

[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, 8 months

1
1
0 0

[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, 8 months

1
0
0 0

[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, 8 months

1
0
0 0

[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, 9 months

3
2
0 0

[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, 9 months

1
1
0 0

[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, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs