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

[xwiki-devs] [Proposal] Remove MenuIT that is not using Docker

by Vincent Massol

Hi devs, Now that the docker-based MenuIT test is working and passing in our CI, I’m proposing to remove the MenuIT version using the XWiki Maven Packager plugin. More Precisely, replace: https://github.com/xwiki/xwiki-platform/tree/ac542d169957d4315fc4eb9d7329a5… by https://github.com/xwiki/xwiki-platform/tree/b4432820f7c3f9e9c13d4767b51454… Note that this means you need to have docker installed locally if you need to run the functional tests for the menu module. Ok with everyone? Thanks -Vincent

6 years, 10 months

2
4
0 0

[xwiki-devs] [ANN] XWiki 10.9 released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 10.9. Starting with this release the Activity Stream Application is fully replaced by the Notifications Application. The list of followed users is back in the user profile and the Page Index can be sorted by page title. The Users and Groups administrations sections have been improved and there's a new Page Picker Velocity macro that can be used by developers. 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.9/ Thanks for your support -The XWiki dev team

6 years, 10 months

1
0
0 0

[xwiki-devs] [Proposal] Move Doxia-based syntaxes in contrib

by Vincent Massol

Hi, In the direction of keeping in commons/rendering/platform only modules that are used in the XS distribution, I’m proposing to move Doxia-based syntaxes to contrib (APT, Docbook & TWiki), in a single doxia github repository (doxia-common, doxia-twiki, doxia-docbook, doxia-twiki). WDYT? Thanks -Vincent

6 years, 10 months

6
5
0 0

[xwiki-devs] BFD#194

by Oana-Lavinia Florean

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

6 years, 10 months

1
1
0 0

[xwiki-devs] [release] 10.9RC1 skipped

by Marius Dumitru Florea

Hi devs, It took us a lot of time to stabilize the build and now we're too late to release 10.9RC1 (was planned 4 days ago) so I'm going to skip 10.9RC1 and release directly 10.9 instead, next Monday (29th of October). Thanks, Marius

6 years, 10 months

2
2
0 0

[xwiki-devs] [Best Practice] Use lowercase for JIRA labels

by Vincent Massol

Hi, I’d like to propose to use a consistent naming scheme for jira labels and use lowercase (and fix all the upper case we can find). Ok for everyone? Thanks -Vincent

6 years, 10 months

5
7
0 0

[xwiki-devs] What do we do with Watchlist and Activity Stream

by Guillaume Delhumeau

Hi. For 10.9RC1, my objective was to stop bundling the Activity Stream UI in the default flavor. Several months before, I did the same with the Watchlist. Now both of them are replaced by Notifications. Even if they are not bundled anymore by default, I have let the modules in the "platform" repository. The idea was to maintain them until 11.x is started (while we stabilize notifications), and to move them in "attic" at the beginning of next year. Recently, while removing Activity Stream calls in our wiki pages, I discovered some code in the User Profile that was handling both Activity Stream and the Watchlist. I removed it, since it was handling deprecated code. But maybe I should have not, since the modules are not moved into the "attic" repository yet. Anyway, it is not clean to have special code for AS and Watchlist in the User Profile module, we need to create a proper mechanism to inject code into the user profile (see: https://jira.xwiki.org/browse/XWIKI-12639). The removing of the code has broken some functional tests in the watchlist module, that were precisely testing this code. So now, we have several options: A - Put back the code I have removed, until Activity Stream UI and Watchlist are moved outside the "platform" repository. So the build would be fixed. B - Remove the failing functional test since it is testing a code we have been removed. So the build would be fixed. C - Put back the code I have removed, but inside the Watchlist module and injected into the User profile via a clean injection system (again: https://jira.xwiki.org/browse/XWIKI-12639). The build would be fixed but it requires more time to develop, and we risk to miss 10.9RC1. The release of 10.9RC1 is already late, so what do you think is the best option? Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

6 years, 10 months

4
3
0 0

[xwiki-devs] [New extension request] Cryptpad Application

by Clément Aubin

Hi everyone, With Anca and Ludovic, we would like to create a new contrib extension that would allow an XWiki instance to communicate with a Cryptpad server in various ways. This could include: * Import / export of document from / to the Cryptpad server * Editing of Cryptpad documents through XWiki * Backup of Cryptpad documents to XWiki * … I'll handle the creation of the extension repository and of the JIRA project. Thanks, Clément

6 years, 10 months

1
1
0 0

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

by Oana-Lavinia Florean

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

6 years, 10 months

1
1
0 0

[xwiki-devs] [STAMP/Test] Metrics we need to improve + strategy

by Vincent Massol

Hi devs (and anyone else interested to improve the tests of XWiki), History ====== It all started when I analyzed our global TPC and found that it was going down globally even though we have the fail-build-on-jacoco-threshold strategy. I sent several email threads: - Loss of TPC: http://markmail.org/message/hqumkdiz7jm76ya6 - TPC evolution: http://markmail.org/message/up2gc2zzbbe4uqgn - Improve our TPC strategy: http://markmail.org/message/grphwta63pp5p4l7 Note: As a consequence of this last thread, I implemented a Jenkins Pipeline to send us a mail when the global TPC of an XWiki module goes down so that we fix it ASAP. This is still a development in progress. A first version is done and running at https://ci.xwiki.org/view/Tools/job/Clover/ but I need to debug it and fix it (it’s not working ATM). As a result of the global TPC going down/stagnating, I have proposed to have 10.7 focused on Tests + BFD. - Initially I proposed to focus on increasing the global TPC by looking at the reports from 1) above (http://markmail.org/message/qjemnip7hjva2rjd). See the last report at https://up1.xwikisas.com/#mJ0loeB6nBrAgYeKA7MGGw (we need to fix the red parts). - Then with the STAMP mid-term review, a bigger urgency surfaced and I asked if we could instead focus on fixing tests as reported by Descartes to increase both coverage and mutation score (ie test quality), since those are 2 metrics/KPIs measured by STAMP and since XWiki participates to STAMP we need to work on them and increase them substantially. See http://markmail.org/message/ejmdkf3hx7drkj52 The results of XWiki 10.7 has been quite poor on test improvements (more focus on BFD than tests, lots of devs on holidays, etc). This forces us to have a different strategy. Full Strategy proposal ================= 1) As many XWiki SAS devs as possible (and anyone else from the community who’s interested ofc! :)) should spend 1 day per week working on improving STAMP metrics * Currently the agreement is that Thomas and myself will do this for the foreseeable future till we get some good-enough metric progress * Some other devs from XWiki SAS will help out for XWiki 10.8 only FTM (Marius, Adel if he can, Simon in the future). The idea is to see where that could get us by using substantial manpower. 2) All committers: More generally the global TPC failure is also already active and dev need to modify modules that see their global TPC go down. 3) All committers: Of course, the jacoco strategy is also active at each module level. STAMP tools ========== There are 4 tools developed by STAMP: * Descartes: Improves quality of tests by increasing their mutation scores. See http://markmail.org/message/bonb5f7f37omnnog and also https://massol.myxwiki.org/xwiki/bin/view/Blog/MutationTestingDescartes * DSpot: Automatically generate new tests, based on existing tests. See https://massol.myxwiki.org/xwiki/bin/view/Blog/TestGenerationDspot * CAMP: Takes a Dockerfile and generates mutations of it, then deploys and execute tests on the software to see if the mutation works or not. Note this is currently not fitting the need of XWiki and thus I’ve been developing another tool as an experiment (which may go back in CAMP one day), based on TestContainers, see https://massol.myxwiki.org/xwiki/bin/view/Blog/EnvironmentTestingExperiment… * EvoCrash: Takes a stack trace from production logs and generates a test that, when executed, reproduces the crash. See https://markmail.org/message/v74g3tsmflquqwra. See also https://github.com/SERG-Delft/EvoCrash Since XWiki is part of the STAMP research project, we need to use those 4 tools to increase the KPIs associated with the tools. See below. Objectives/KPIs/Metrics for STAMP =========================== The STAMP project has defined 9 KPIs that all partners (and thus XWiki) need to work on: 1) K01: Increase test coverage * Global increase by reducing by 40% the non-covered code. For XWiki since we’re at about 70%, this means reaching about 80% before the end of STAMP (ie. before end of 2019) * Increase the coverage contributions of each tool developed by STAMP. Strategy: * Primary goal: ** Increase coverage by executing Descartes and improving our tests. This is http://markmail.org/message/ejmdkf3hx7drkj52 ** Don’t do anything with DSpot. I’ll do that part. Note that the goal is to write a Jenkins pipeline to automatically execute DSpot from time to time and commit the generated tests in a separate test source and have our build execute both src/test/java and this new test source. ** Don’t do anything with TestContainers FTM since I need to finish a first working version. I may need help in the future to implement docker images for more configurations (on Oracle, in a cluster, with LibreOffice, with an external SOLR server, etc). ** For EvoCrash: We’ll count contributions of EvoCrash to coverage in K08. * Secondary goal: ** Increase our global TPC as mentioned above by fixing the modules in red. 2) K02: Reduce flaky tests. * Objective: reduce the number of flaky tests by 20% Strategy: * Record flaky tests in jira * Fix the max number of them 3) K03: Better test quality * Objective: increase mutation score by 20% Strategy: * Same strategy as K01. 4) K04: More configuration-related paths tested * Objective: increase the code coverage of configuration-related paths in our code by 20% (e.g. DB schema creation, cluster)related code, SOLR-related code, LibreOffice-related code, etc). Strategy: * Leave it to FTM. The idea is to measure Clover TPC with the base configuration, then execute all other configurations (with TestContainers) and regenerate the Clover report to see how much the TPC has increased. 5) K05: Reduce system-specific bugs * Objective: 30% improvement Strategy: * Run TestContainers, execute existing tests and find new bugs related to configurations. Record them 6) K06: More configurations/Faster tests * Objective: increase the number of automatically tested configurations by 50% Strategy: * Increase the # of configurations we test with TestContainers. I’ll do that part initially. * Reduce time it takes to deploy the software under a given configuration vs time it used to take when done manually before STAMP. I’ll do this one. I’ve already worked on it in the past year with the dockerization of XWiki. 7) K07: Pending, nothing to do FTM 8) K08: More crash replicating test cases * Objective: increase the number of crash replicating test cases by at least 70% Strategy: * For all issues that are still open and that have stack traces and for all issues closed but without tests, run EvoCrash on them to try to generate a test. * Record and count the number of successful EvoCrash-generated test cases. * Derive a regression test (which can be very different from the negative of the test generated by evocrash!). * Measure the new coverage increase * Note that I haven’t experimented much with this yet myself. 9) K09: Pending, nothing to do FTM. Conclusion ========= Right now, I need your help for the following KPIs: K01, K02, K03, K08. Since there’s a lot to understand in this email, I’m open to: * Organizing a meeting on youtube live to discuss all this * Answering any questions on this thread ofc * Also feel free to ask on IRC/Matrix. Here’s an extract from STAMP which has more details about the KPIs/metrics: https://up1.xwikisas.com/#QJyxqspKXSzuWNOHUuAaEA Thanks -Vincent

6 years, 11 months

4
15
0 0

[xwiki-devs] [UX][Proposal] Distribution Wizard: Never Button

by Ecaterina Moraru (Valica)

Hi devs, This is an improvements proposal for the "Never" button from Distribution Wizard. https://design.xwiki.org/xwiki/bin/view/Proposal/Upgrade/DWNeverButton/ I've listed several variants of fixing the usability issue, let me know which one is your favorite. My +1 goes to VAR2: Confirmation; with minimum we can do being VAR1: Location. Thanks, Caty

6 years, 11 months

3
7
0 0

[xwiki-devs] [ANN] XWiki 9.11.8 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 9.11.8. This is a bugfix release that covers important issues that we have discovered since 9.11.7 has been released. 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.8 Thanks for your support -The XWiki dev team

6 years, 11 months

1
0
0 0

[xwiki-devs] [Proposal] Change ObservationManager behaviour with CancelableEvents

by Simon Urli

Hi everyone, the current behaviour of the ObservationManager is to always triggers the listeners if it matches the events. Now regarding the CancelableEvents, the match is only done on the type of the event and some given filter rules, but never with its cancel status: if an event is cancelled, the matching listeners are always triggered. I propose to change that behaviour, to trigger listeners only if the CancelableEvents are not canceled: basically, a cancelled event wouldn't match any listener. My primary reason for wanting that change is that the current behaviour led to a bad UX: if an event triggers multiple questions, no matter if one is cancelled, all questions will be asked to the user. Do you know if the current behaviour is required at some places? Else do you agree on changing it? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

6 years, 11 months

4
8
0 0

[xwiki-devs] [Proposal] Prevent users from renaming/move pages with XClass definition

by Simon Urli

Hi all, users might currently break their AWM application by renaming/moving pages containing XClass definition. We need a proper refactoring operation to be able to properly do such move/rename. But this feature might take a while to be completely available. In the meantime I propose that we prevent users from renaming/moving pages containing XClass. What I propose is the following: - Forbid completely *simple users* to rename/move pages containing XClass - Display a warning to *advanced users* when they perform such operation: the same kind of warning we already have when performing edit on XWiki pages WDYT? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

6 years, 11 months

6
28
0 0

[xwiki-devs] Fwd: [xwiki/xwiki-commons] One of your dependencies may have a security vulnerability

by Vincent Massol

nice… Even though we rolled back this upgrade since it has regressions ;) -Vincent > Begin forwarded message: > > From: GitHub <notifications(a)github.com> > Subject: [xwiki/xwiki-commons] One of your dependencies may have a security vulnerability > Date: 16 October 2018 at 19:02:58 CEST > To: xwiki/xwiki-commons <xwiki-commons(a)noreply.github.com> > Cc: Security alert <security_alert(a)noreply.github.com> > Reply-To: xwiki/xwiki-commons <noreply(a)github.com> > > <https://github.com/> Sign in <https://github.com/login> > vmassol, > We found a potential security vulnerability in a repository for which you have been granted security alert access. > > xwiki/xwiki-commons <https://github.com/xwiki/xwiki-commons> > Known moderate severity security vulnerability detected in org.dom4j:dom4j < 2.1.1 defined in pom.xml <https://github.com/xwiki/xwiki-commons/blob/master/pom.xml>. > pom.xml <https://github.com/xwiki/xwiki-commons/blob/master/pom.xml> update suggested: org.dom4j:dom4j ~> 2.1.1. > Always verify the validity and compatibility of suggestions with your codebase. > Review vulnerable dependency <https://github.com/xwiki/xwiki-commons/network/alert/pom.xml/org.dom4j:dom4…> > > Only users who have been assigned access to security alerts will receive these notifications. > > Unsubscribe <https://github.com/notifications/unsubscribe-vulnerability/AAmWKxhmdIzJDKAX…>· Email preferences <https://github.com/settings/emails> · Terms <https://help.github.com/articles/github-terms-of-service/> · Privacy <https://help.github.com/articles/github-privacy-policy/> · Sign into GitHub <https://github.com/login> > > GitHub, Inc. > 88 Colin P Kelly Jr St. > San Francisco, CA 94107 >

6 years, 11 months

1
1
0 0

[xwiki-devs] [ANN] XWiki 10.8.1 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 10.8.1. This is a bugfix release that covers important issues that we have discovered since 10.8 has been released. 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.8.1 Thanks for your support -The XWiki dev team

6 years, 11 months

1
0
0 0

[xwiki-devs] State of Velocity 2.0 upgrade

by Thomas Mortagne

Hi devs, Some of you may know that I started working on upgrading our scripting engine to Velocity 2.0. The corresponding Jira issue is https://jira.xwiki.org/browse/XCOMMONS-1296. Those of you who want to take a look at breakages with standard Velocity 2.0 upgrade (if you directly use Velocity API) can take a look at http://velocity.apache.org/engine/2.0/upgrading.html. The following details are about XWiki Velocity "engine": = The code You can see the current state of the upgrade on the following branches: * https://github.com/xwiki/xwiki-commons/tree/feature-velocity2 * https://github.com/xwiki/xwiki-rendering/tree/feature-velocity2 * https://github.com/xwiki/xwiki-platform/tree/feature-velocity2 = Bad news == Definitive (probably) breakages * it was not easy in Velocity 1.7 but it's now impossible in Velocity 2.0 to use the hack we currently use to make macro "return" something. I mitigated this a bit by working on a #setVariable directive (the name of the helper we currently have in macros.vm) but it's not yet working in all situations and any code that was not going trough #setVariable will be broken anyway * the hypen ( - ) cannot be used in variable names anymore Those changes make impossible to upgrade to Velocity 2.0 in 10.x branch IMO, to big to be done in the middle of a cycle. == Temporary (hopefully) breakages * impossible to have $ or # at the end of a " based string literal (we have that a lot in various regex for example). This looks like an unplanned regression (since it's not documented) so I'm waiting for some kind reaction in the issues I reported (https://issues.apache.org/jira/browse/VELOCITY-897 and https://issues.apache.org/jira/browse/VELOCITY-896) == Not too impacting (hopefully) breakages The Velocity API changed quite a lot, fortunately not in classes we expose publicly (basically all we expose is VelocityContext). Also reminder: directly manipulating even XWiki Velocity API is considered legacy things (better use templates or wiki content and ScriptContext). = Good news == Macros handling The way to manage namespaces and macros has been completely changed (it does mean that lots of API has been broken in the process but we don't expose this API) and the good news is the new design will allow us to (finally) do proper caching of velocity scripts. I also removed a few hacks we had to do to not end up with endless memory leaks and milti-thread issues caused by the old namespace handling system. == Less stuff on our side I was able to move the following to legacy: * an equivalent of our chainable uberspector system has been implemented in Velocity standard * a DeprecatedCheckUberspector has been implemented in Velocity standard == Retro compatibility I was able to add * XWiki will keep supporting $velocityCount and $velocityHasNext (with a warning). It imply using XWikiVelocityContext instead of VelocityContext if you create it directly (which is a very bad idea) but you don't need to worry about that if you get your context from VelocityManager * a new #setVariable directive help supporting a few use case of macro "return" but unfortunately not all yet (Velocity AST is not super obvious to navigate...) == Performances Other than the caching on our side I already mentioned (huge boost planned when implemented) there is some memory and performance improvements claims in Velocity 2.0 release note (but I did not had time to do any testing myself yet). = TODO a) waiting for answer about the regressions I reported b) try find a way to make #setVariable directive works in a macro which is itself called in another macro (but it may not be possible) c) send a mail to discuss when to merge the Velocity 2 branch when at least a) is resolved Thanks, -- Thomas Mortagne

6 years, 11 months

1
1
0 0

[xwiki-devs] Proposal for Macro inline edition

by Simon Urli

Hi everyone, I'm working on the roadmap issues related to the inline edition with WYSIWYG editor for macro content and macro parameters. The first step is to add a flag to allow user specify that a content or a parameter can be edited inline with the WYSIWYG editor. The second step is to allow the CKEditor to detect where the content and/or parameters should be edited. Let's take the exampe of a simple macro without any parameter, which currently produces this code: <div class="box infomessage"> <div class="title"> <span class="icon info"></span> some title </div> Some content </div> We propose (me & Marius) to ask users to add a wrapper with a specific class around the content to tell the editor it should only allow editing this content, e.g.: <div class="box infomessage"> <div class="title"> <span class="icon info"></span> some title </div> <span class="editable-content">Some content</span> </div> About parameters, our idea was to define a new metadata attribute and to ask users to use it for specifying the content is editable, such as for a parameter named foo: <span class="editable-content" data-parameter="foo">my foo parameter value</span> However I don't know right now how the editor would manage cases such as: <span class="editable-content">Some content with <span class="editable-content" data-parameter="myparameter">a parameter</span></span> So: 1. Do you agree on the usage of a class named "editable-content" which would be used as a tag to allow inline edition? 2. WDYT about using a data-parameter and this class for inline editing of parameters? Thanks, Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

6 years, 11 months

5
34
0 0

[xwiki-devs] [Documentation] Upgrade

by Ecaterina Moraru (Valica)

Hi devs, Since I didn't understood a lot of things the first time I've read the Update documentation, I've made a proposal on improving the grouping of the content. You can see: - The original https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Upgrade - The proposal https://design.xwiki.org/xwiki/bin/view/Proposal/Upgrade/SimplerUpgrade/Dra… Since the content is highly technical, if you find mistakes or want to add stuff, please just edit them yourself. I've just took the existing content and reorganize it. Let me know what you think about this version and if we can replace the current version with the draft. Thank you, Caty

6 years, 11 months

2
4
0 0

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

by Oana-Lavinia Florean

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

6 years, 11 months

1
1
0 0

[xwiki-devs] [Proposal] Deprecate Document#getName()

by Vincent Massol

Hi devs, I’d like to propose deprecating Document#getName() in favor of Document#getDocumentReference(). The main reason is that it’s misleading since users will use nested pages by default and this method returns “WebHome” all the time in this case. In addition, it doesn’t make sense anymore with nested pages to have access only to the last part of the reference. WDYT? Thanks -Vincent

6 years, 11 months

2
1
0 0

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

by Oana-Lavinia Florean

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

6 years, 11 months

1
1
0 0

[xwiki-devs] [Brainstorming] "Code" subspace for apps

by Vincent Massol

Hi devs, I’ve just had a quick chat with Edy and I found that we had a difference of opinion on the Code subspace practice. On https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPr… we say: "Technical pages must be put in a subspace named Code” Now Edy says that this should be done only for data-generating apps. It’s not my recollection that this rule was only for this case and this is what I’d like to discuss here. For example, I’ve noticed that ActiveInstalls has all technical pages under ActiveInstalls, see https://github.com/xwiki/xwiki-platform/tree/053f0a2757cea18a5916632a58c604… I would fix it to have only the WebHome remain under ActiveInstalls and move all the technical pages under ActiveInstalls.Code. The only case where it could make sense to not have a Code subspace would be when the app has no UI at all. Even in this case, you might argue that we should always have a home to provide a description about the content of the space. So right now I’m personally in favor of continuing the rule we defined in the best practices: "Technical pages must be put in a subspace named Code” WDYT? Thanks -Vincent

6 years, 11 months

5
6
0 0

[xwiki-devs] [Proposal] Turn off redirects in page move/rename

by Vincent Massol

Hi devs, We see more and more wikis with tons of redirects and issues to manage them, see https://jira.xwiki.org/browse/XWIKI-14570 “ Rationale for turning it off by default: - Several users have reported a usability issue about automatic redirects. The way they express it is the following: "I have duplicates pages in my wiki. I don't understand why this is happening. I'm choosing to rename pages and not to copy them but I still get duplicates in the Navigation panel". - Automatic redirects are especially useful for public wikis where users can have bookmark on pages and you don't want to break them. It can also be useful for internal wikis but it's less an issue. - Even for public wikis not all pages need automatic redirects. Technical pages don't need them for example. “ I’ve had Ludovic report that to me too again this morning. Since we’ve been knowing about the problem for a while already and since it’s very easy to change the default behavior, I’d like to propose that we turn it off by default in XWiki 10.8 (ie right now, or if you think it’s really too dangerous in 10.9), and that we implement an option to configure the default behavior later on (https://jira.xwiki.org/browse/XWIKI-13384). WDYT? Thanks -Vincent

6 years, 11 months

5
9
0 0

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

by Oana-Lavinia Florean

Hello devs, This Thursday is BFD#190: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -46 bugs over 120 days (4 months), i.e. we need to close 46 bugs to have created bugs = closed bugs * -96 bugs over 365 days (1 year) * -144 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#190 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14325 Good luck at fixing bugs, Lavinia

6 years, 11 months

1
1
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