xwiki-devs February 2019

xwiki-devs@xwiki.org

12 participants
31 discussions

[xwiki-devs] [VOTE] Use discourse for the "dev" mailing list

by Guillaume Delhumeau

Hi devs, I think we are now satisfied with our experimentation with the "users" mailing list on discourse. I propose you to move the "dev" ML too. My main point is that it allows advanced formatting (which is good when you have complex proposals), meanwhile the formatting is lost with our archiving tool like markmail (it's plain text). Here is my +1. Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

5 years

[xwiki-devs] [Proposal] Update database support strategy

by Vincent Massol

Hi devs, We currently have https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy However, it doesn’t say explicitly which versions we officially support: * For HSQLDB it says 2.3.3 which is wrong since the latest version is 2.4.1 * For MySQL it says 5.x but doesn’t specify which specific version(s) * Same for other DBs We cannot really support every versions since supporting means testing too. So what I propose: Question 1: definition * We say we support the latest stable version of the databases for a given version cycle ** For MySQL, it’s the latest of the 5.x cycle, which is 5.7.24 as of today (see https://hub.docker.com/_/mysql/) ** For PostgreSQL, it’s the latest of the 9.x cycle, which is 9.6.10 as of today (see https://hub.docker.com/_/postgres/) ** For Oracle, it’s the latest of the 11.x cycle, which is 11.2.0.4.0 as of today (see https://www.oracle.com/technetwork/database/enterprise-edition/downloads/in…) Question 2: review what we support * For MySQL I think we could also start supporting MySQL 8.x (ie the latest version of that cycle). We have an issue open for it currently: https://jira.xwiki.org/browse/XWIKI-15215 * For PostgreSQL we could also start supporting versions 11.x (ie the latest version of that cycle) * For Oracle, we could also start supporting versions 12.x (ie the latest version of that cycle) Question 3: decide if we drop some support * Is there any cycle that we should support for? Right now I think that MySQL 5.x is still heavily used, same for postgreSQL 9.x I guess. Don’t know for Oracle. * Any idea? So WDYT about the 3 questions? Thanks -Vincent

5 years, 4 months

[xwiki-devs] [Proposal] Do not write pure-developer release notes

by Vincent Massol

Hi devs, Context ======= It’s been since we’ve deviated from the original purpose of the Release Notes by also adding developer-oriented release notes. The goal of the Release Notes was to **highlight** important novelties for our **users**, because looking at the JIRA list is too technical (otherwise we could simply use the Release feature of JIRA! :)). So you may ask why we do have a “Developer” Category in the RN app. These were not for pure developers but for XWiki users who are more advanced and can write scripts in wiki pages. And when it’s the case we **must** add examples, otherwise, it’s completely useless. For example this morning I saw this RN added: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.0/Change004/ This is typically something that has very little value to me: * It’s for pure developers (java devs) * It’s not understandable by anyone except the person who coded it or participated to the dev mailing list discussion about it * It doesn’t say more than what’s in the JIRA issue so what’s the point? * There are no examples at all in it! * Real developers can simply look at the reference documentation or can read the JIRAs. We always link the JIRA issues in the RN anyway (it was for this reason that we’re listing them). * It takes time to write RN items and thus it needs to have high value Proposal ======== * Go back to the original idea and only list developer RN items when they are for scripting users and not APIs. For example, document some new script service or some additions to existing script services. Of course Groovy would allow you to call any API so being able to use it from Groovy is not a good criteria. I’d say that the criteria should be whether the Release Note Change is useful for Velocity users. * Rename “Developers” into “Scripters” or or “Advanced Users” (any better name?) * Always put an example when writing a “developer” change and take the time to explain properly what it’s about. WDYT? Thanks -Vincent

5 years, 4 months

[xwiki-devs] OpenCollective for XWiki Community

by Ecaterina Moraru (Valica)

Hi devs, This is a proposal for the content we would have if we were to create an OpenCollective account for XWiki. Take a look at https://design.xwiki.org/xwiki/bin/view/Proposal/XWikiOpenCollective The issues we need to solve / validate are: A. Decide on the URL name (xwiki is already taken by XWiki SAS) B. See if XWiki SAS can act like our Fiscal host C. Validate the tiers and content https://design.xwiki.org/xwiki/bin/view/Proposal/XWikiOpenCollective#HTiers (we might need more details on how the "Bug Fixer" works in case we agree to it) Let me know what you think, Caty

5 years, 4 months

[xwiki-devs] Location for extensions ideas

by Thomas Mortagne

Hi xwikiers, I'm never sure where to put ideas of extensions I have so I often forget them or details I had tough about or gathered back then. I don't think http://design.xwiki.org is the right place until you really start designing the extension. Also it's too generic for this need and not a very good entry point for searching something IMO, more something to link to from somewhere else. I would prefer something really dedicated to this "that would be a nice thingy but not sure about the details yet" state. Would be a good source for hackathons and GSOC or for contributors who are searching for something interesting to work on. I was thinking about the following alternatives: * a new dedicated project on https://jira.xwiki.org * reuse https://jira.xwiki.org/projects/XCONTRIB after some cleanup (close everything left in it basically) but not super clean (it's just that it's a good name) * some new application on http://www.xwiki.org WDYT ? Right now my preference goes to a clean new jira project (just need to think about a good project id) where you put description and close it when the extension work really start on a dedicated location. Less work and should do the job well. -- Thomas Mortagne

5 years, 4 months

[xwiki-devs] [proposal] Process to handle Pull Requests

by Ludovic Dubost

Hi devs, I don't think there is currently a process that is in place to handle pull requests and I have the feeling that the way there are handled today is a bit random. There are usually comments sent out on each pull request but sometimes it seems that some pull requests are going in sleep mode and it's not clear who is in charge. I would like to suggest that a process is put in place where it's clear who is responsible for a pull request and a status is given to the contributors that propose that pull request. Something like: Assigned developer: XXXX Status: New -> new pull request, not yet assigned Assigned -> assigned to a developer, he is in charge of reviewing the pull request and ask for modifications or accept it. The developer can auto assign it to himself. If nobody does, we need to decide how they will be taken into account. ModificationsRequired -> for now rejected with comments. Contributor needs to apply comments and then change back to Assigned for further evaluation VoteRequired -> there are no more comments, but a vote is required as the changes to XWiki core are important WaitingFinalAuthorization -> optional step for complex patches where a additional authorization would be required (need to define who would be the persons that give the authorization) WaitingApplication -> there are no more comments and no changes or vote required. The pull request can be applied and is waiting for a developer to apply it Abandoned -> contributors is abandoning the pull request (cannot do the changes, no more time, etc..) Rejected -> pull request is rejected (quality not enough, etc..) Applied -> pull request is applied What do you think ? Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

5 years, 4 months

[xwiki-devs] [WCAG] Reference validator

by Ecaterina Moraru (Valica)

Hi devs, I've started to analyze the 971 tests failing on webstandards related to the WCAG validation. I plan to create issues in order for us to fix the errors. The problem I have is that we were validating against the Dutch Guidelines validation tool (previously http://www.webrichtlijnen.nl/english/testing) but this tool has been discontinued by the Dutch Ministry in July 2017, see https://www.digitoegankelijk.nl/onderwerpen/testen/nieuws/2017/04/25/gewoon… The difference between the W3C WCAG rules (https://www.w3.org/TR/WCAG/) and the Dutch Guidelines was that the latest were more strict. Also WCAG specification advanced to version 2.1 in Jun 2018. Since I don't have much experience in the way we've implemented the validator, I'm asking if anyone has any idea of another validator we could replace this one with (in case we want this). Else, I will try to investigate and find a replacement for a new reference validator. Currently the plan is to fix our code to match the current definitions and in cases that are not covered by W3C WCAG and where we want to add "exceptions" I test also online on: * https://ckeditor.com/ckeditor-4/accessibility-checker/ and * http://wave.webaim.org/ Let me know if you have any objections to the 2 tools mentioned above. I've started the investigation at: https://design.xwiki.org/xwiki/bin/view/Proposal/WCAG10x we can discuss each error and "exception" on the individual issues. Thanks, Caty

5 years, 6 months

[xwiki-devs] Status on Docker + CI + Clover - Outstanding tasks

by Vincent Massol

Hi devs, I wanted to keep up to date on the list of stuff that we still need to do in the domain of Docker, CI & Clover, specifically on the domains I’ve been working on. All the items below are items I need to work on (but any help is welcome of course). 1) Clover pipeline job to modify to add docker-based functional tests: right now the global TPC is going to decrease because of MenuIT and MailIT. This needs to be fixed ASAP before we convert too many tests. 2) Also fix Clover pipeline job in general which hasn’t passed since the 22nd of October 3) Execute Docker-based tests in main pipeline job for the default config as otherwise we might have the platform job succeeding but it’ll miss several functional tests! Option 1: execute Browser outside of docker as option, Option 2: add more docker-based agents. For the moment, we might be able to run the docker tests on agent4. 4) Screenshot attachment on UI test failures to fix in pipeline job 5) Flicker recognition on tests to fix in pipeline job 6) Fix the ClosedChannelExcption/InterruptedException in our CI 7) Research running Jenkins agents in docker images and make our Docker test work (docker on docker). Once this works, set up 2 or 2 agents on a4. And then move all other agents to this. 8) Still need to apply the Clover strategy we agreed on (global TPC needs to not go down during releases). 9) Find strategy to move Docker image creation in platform build Let me know if you have questions. Thanks -Vincent PS: I didn’t list fixing tests (such and flicker fixing or WCAG test fixing) since this not infra and I wanted to limit this list to infra.

5 years, 7 months

[xwiki-devs] [ Brainstorming] Improving XWiki installation - Increase Active Installs

by Vincent Massol

Hi devs, I believe one very important action to improve active installs is to improve installation of XWiki. I’ve started listing ideas at https://design.xwiki.org/xwiki/bin/view/Proposal/InstallationImprovementIde… Let me know what you think. I think I’d like to propose to work on this aspect after 11.2 is out. WDYT? Thanks -Vincent

5 years, 7 months

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

by Oana-Lavinia Florean

Hello devs, This Thursday is BFD#209: 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 * -132 bugs over 365 days (1 year) * -147 bugs over 500 days (between 1 and 2 years) * -339 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#209 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14404 Good luck at fixing bugs, Lavinia

5 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2019