Hi devs,
Stephane Lauriere was asking us to have admin rights for the chartjs contrib project so that he could do a release.
Right now only the owner + global jira admins have admin rights.
I’m proposing to change the current Administrator role for JIRA Contrib Projets from:
* jira-administrators
to:
* jira-administrators
* contrib-committers
* xwiki-committers
WDYT?
Thanks
-Vincent
Hi devs,
In order to have ci.xwiki.org use docker-based agents (i.e. master will spawn agents using a pre-built docker image), I need to create a github repository to hold the Dockerfile for that docker image, and so that the xwiki dockerhub organization can have an automated build to build it regularly.
I’m thus proposing to create a new "xwiki-jenkins-slave” repository in the xwiki github org.
Since I’m working on this now, I’ll go ahead and create the repo and I can remove it if someone disagrees.
Thanks
-Vincent
Hi devs,
I’d like to refactor the groovy code that I’ve currently put at https://github.com/xwiki/xwiki-jenkins-pipeline/blob/59051fd8f61bd5a65db790… and to move it into an XWiki Maven plugin for Clover.
The goal of this plugin is to take as input two clover.xml Clover data files and to generate a diff report (example: http://maven.xwiki.org/site/clover/20181120/XWikiReport-20171222-1835-20181…).
Rationale for move this outside of Jenkins:
* Less dependency on Jenkins
* Much easier to test
* Better versioning and release
* Increased reuse (any project in the world will be able to use it whereas the pipeline is specific to xwiki and not reusable easily)
It’s not linked to releases of XWiki. But it should be maintained by the xwiki dev team since we use it in our pipeline to compute the global coverage and generate reports/emails when global TPC is lowered.
WDYT?
Thanks
-Vincent
Hello all,
The XWiki development team is proud to announce the availability of XWiki
10.10.
In this version, a new protection helper was introduced to prevent users
from breaking the wiki when an XClass page is being refactored, PDF export
looks better now and the new auto-suggestion feature starts to be enabled
in some places.
It's now possible to easily enable asynchronous execution and caching for
panels, wiki UI extensions and wiki macros, this making the rendering of
the page faster.
Among other things, Wiki Macros can now have typed parameters and it is now
possible to make the content of a macro editable inline with the WYSIWYG
editor.
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.10/
Thanks for your support
-The XWiki dev team
Hello devs,
There are some issues in progress for 10.10 release + some testing for them
so
I propose to postpone the release for tomorrow.
Thanks,
Alex
Hi everyone,
one of the most validation error we have with WCAG is about consecutive
line breaks: basically a <br /><br /> presents in a page.
This happens mostly in our translation pages since the linebreaks in
plain syntax are translated in <br /> tags.
Caty provided a lot of details about this error on the related issue:
https://jira.xwiki.org/browse/XWIKI-15666.
Currently we have around 140 validations failure because of this.
Different proposal have been made in order to fix it, that I will try to
sum-up here:
A. Remove completely this validation check
B. Add an exception for the translation pages
C. Triggers the error only if more than 2 consecutive breaks is
encountered
D. Create a rendering syntax dedicated to translation pages
A. Remove completely the validation check
pros:
* the easiest one
* apparently the rule is not checked in other accessibility test, so
its real purpose for accessibility is unclear
cons:
* IMO this rule is useful for checking the good practice of not using
<br />
B. Add an exception for the translation pages
pros:
* same as for A
cons:
* ?
C. Triggers the error only if more than 2 consecutive breaks is encountered
pros:
* ?
cons:
* we would miss some consecutive <br /> that are used only for style
and we would catch some others in translations if we do 3 linebreaks
instead of 2. IMO it's only moving the problem
D. Create a rendering syntax dedicated to translation pages
pros:
* remove completely the problem of consecutive <br /> in translations
* can maybe be used to present them in another way?
cons:
* need to develop/test/maintain a new rendering syntax
I'd personnaly vote like this:
A: +0
B: +1
C: -1
D: +0
WDYT?
Simon
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com