Hi devs,
Here’s a roadmap proposal for XS 10.4, 10.5 & 10.6
So here’s a proposal which takes into account remaining work + try to go in the directions defined at https://forum.xwiki.org/t/brainstorming-xwiki-10-x-cycle-roadmap/2274 (globally meaning more usability for end users).
XS 10.4
=======
* Date: May
* Thomas: Finish work for edit protection from 10.3. Specifically ability to prevent editing/moving/deleting extension pages when a confi param is set for that.
* Thomas: Register global wiki macro at wiki level when the macro document is in a subwiki - http://jira.xwiki.org/browse/XWIKI-12736
* Thomas: Performance work. Goal: be as good as XWiki 8.4.x. Fix performance issue in XWiki 10.x/Investigate problems with notifications. See for ex https://forum.xwiki.org/t/xwiki-and-tomcat-crashes/2788 but several users have reported issues so there's definitely something really bad happening.
* Guillaume: Finish AS replacement + continue fixing Notifications problems
* Marius: Improve Navigation panel. Introduce notion of blacklist for the Navigation panel and provide an Admin UI for it. Goal: remove the XWiki space by default using this blacklist (users can be seen in the User Index). Allow users to control better what they have in the panel + control the order. Others: try to improve performance.
* Adel: Evaluate and implement weblate for XWiki (replacement for l10n). Note: weblate is moving fast: https://docs.weblate.org/en/latest/changes.html
XS 10.5
=======
* Date: June
* Thomas: continue work on performance (started in 10.4)
* Thomas: Fix inconsistence of WebHome appearing everywhere when using references in macros and API calls. Finish Nested Spaces/Pages work. Page API.
* Guillaume: Notifications bugfixes
* Marius/Adel: Autocomplete on reference. Note: This would lessen the issue with WebHome.
* Example 1: In object editor when the type is "Page Reference" + picker
* Example 2: In WYSIWYG macro editor when a macro has a reference parameter + picker
* Marius/Adel: Finish Visible Save implementation
XS 10.6
=======
* Date: July
* Thomas: continue work on performance (started in 10.4)
* Thomas: Bug fixes (ongoing)
* Guillaume: Notifications bugfixes
* Marius/Adel: For macros having wiki markup content (need new macro descriptor metadata), let the user enter it in the WYSIWYG directly. When hovering over the macro allow editing content + have some icons to edit parameters (similar to the CKEditor easy image feature: https://github.com/ckeditor/ckeditor-dev/issues/932 They call it a "balloon toolbar").
* Marius/Adel: Move Menus inside administration (see http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaMenuInAdministration)
Let me know if you have any feedback.
@Assignees: As always, please create jira issues and update the roadmap page with the jira issues (I’ll update the roadmap page now).
Thanks
-Vincent
The XWiki development team is proud to announce the availability of XWiki 10.3.
In this version you will automatically get notification when change
are made to pages you worked on. It also introduce the protection
against edition of pages coming from extensions to avoid breaking
mistakes and ease upgrades.
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.3
Thanks for your support
-The XWiki dev team
Hi,
I’d like to modify the Release Notes app to autogenerate summaries for releases.
The idea is to auto generate it based on the headings for user , admins and devs headers.
For ex, taking the 10.2 release notes it would give:
"For users: New default Color Theme, Figure Macro, Rename/Move protection and Minor changes do not generate notifications anymore. For admins: Default Notifications. For Developers: REST API now supports the use of minor revision for page changes, Translation fallback and Jobs improvements."
It's not too bad IMO.
WDYT?
Thanks
-Vincent
Hi,
Today was supposed to be the release of 10.3 RC1. However, due to various
reasons (the stabilization of the release resulted in reverting the most
important part of the work done for this release, missing documentation,
etc.) and to avoid spending more time on almost empty releases instead of
the features themselves, we have decided that it's best to skip the 10.3
RC1 release and jump directly to 10.3 Final, next week.
I will be updating the version on jira as well to remove 10.3 RC1 and move
the existing issues to 10.3.
Some code changes need to be done as well for the @Since annotations
mentioning 10.3RC1 that will have to be switched to 10.3. (will leave that
to the devs that added them)
Thanks and sorry for the inconvenience,
Eduard
Hi,
I’ve posted the following on matrix/IRC.
Friday:
* Guys we regressed in global TPC from 2017-11-09 to 2018-04-03 :(
* From 76.28% to 75.88%
* we need to analyze more in details now to understand why
* (and whether the report is correct or not)
* PDF Report: https://up1.xwikisas.com/#mJ0loeB6nBrAgYeKA7MGGw
* Examples:
** com.xpn.xwiki.internal.store from 97.6% to 89.32%
** com.xpn.xwiki.internal.file from 67.9% to 9.87% - that's huge maybe some refactoring
** org.xwiki.url.internal from 86.99% to 63.69%
Today:
* Note that I have 2 reasons for checking our TPC:
** Globally it has to go up every year and we've gone down since nov 2017
** For STAMP we need to show an increase in TPC and we had a nice +2.2% increase from 2016 to 2017 but we've gone down now and we need to go up, to go to +3 or/ 4% at end of 2018
Today I’ve also started analyzing the drop from 67.9% to 9.87% for “com.xpn.xwiki.internal.file”. Here are my findings:
* This is caused by TemporaryDeferredFileRepository which is no longer tested
** Before: http://maven.xwiki.org/site/clover/20171109/clover-commons+rendering+platfo…
** After; http://maven.xwiki.org/site/clover/20180403/clover-commons+rendering+platfo…
* There have been refactoring recently to enable FS attachment store by default that have led to TemporaryDeferredFileRepository not being used anymore (deprecated methods not used anymore) or used only in some specific circumstances (for example at https://github.com/xwiki/xwiki-platform/blob/ac85d61b0c48d7ed21a8109e964f77… the store is not defined)
* The conclusion is that before the changesTemporaryDeferredFileRepository was called a lot (indirectly) leading to 545 calls to it (http://maven.xwiki.org/site/clover/20171109/clover-commons+rendering+platfo…) and now it’s not called anymore at all.
* The second conclusion is that we had no unit/integration tests for it and the changes lead to loosing it being tested. So it’s no longer tested ATM. Thanks to the Clover report we noticed that it’s no longer tested.
* Thus we need to do one of 2 things:
** Move the code to legacy and make sure no code uses it. That’s if we don’t really need it
** Keep it but add some unit/integration tests or even some functional tests that would trigger it.
I’ll let Thomas pitch in on this.
Next step: analyze some other drops in TPC.
Note: I wish it were simpler to find out why some TPC drops. Took me like 1-2 hours to figure all this out...
Thanks
-Vincent
Hi devs,
I’ve had some fun this week end implementing the equivalent of MockitMockingComponentRule, MockitoComponentManagerRule & ComponentManagerRule (and more).
See https://jira.xwiki.org/browse/XCOMMONS-1392 for more details.
Let me know what you think. If we don’t like it I can remove it for 10.3RC1 or 10.3 final.
FTR I’ve read https://junit.org/junit5/docs/current/user-guide/#overview and I find JUnit5 so powerful :) I love it.
Thanks
-Vincent
Hi devs,
Context
======
Evocrash is a tool developed as part of the STAMP research project (https://www.stamp-project.eu/). Its goal is to take a stack trace (the use case is production stack traces) and generate a test that, when executed, reproduces the stack trace ;)
It’s using Guided Genetic Algorithm to simplify the search space (which is pretty cool, isn’t it? ;)). More info at https://github.com/STAMP-project/EvoCrash and http://www.evocrash.org/
Results
======
So far evocrash was able to generate tests for the following issues (I’ve pasted the generated test code as comment):
* https://jira.xwiki.org/browse/XRENDERING-422
* https://jira.xwiki.org/browse/XWIKI-14475
* https://jira.xwiki.org/browse/XWIKI-13031
* https://jira.xwiki.org/browse/XWIKI-13196
* https://jira.xwiki.org/browse/XWIKI-13916
Using
=====
The use case I see is the following:
* A user reports a problem when using XWiki and create a jira issue with a stack trace
* An XWiki dev finds it and runs evocrash to generate a test reproducing the problem
* The XWiki dev uses the test to understand the reason (breakpoints can be put in the IDE) of the problem and writes a better test (which can be inspired by the test generated by evocrash or be completely different).
Questions
========
The question we need to answer is whether we think it coud be useful or not. Are there cases where it can be useful?
For example if we imagine someone not knowing the xwiki code base well, maybe this can help him/her understand the bug in a simpler way than just having to read/find where the problem is in the code base?
I’ve started the work of trying to evaluate how useful it could be on the XWiki project by analyzing the examples above. I've only analyzed 2 ATM (see the links in the jira comments) and I’d be interested to have your analysis too.
WDYT?
Thanks
-Vincent