December 2018 - xwiki-devs@xwiki.org

[xwiki-devs] [ANN] Definition of Cycle Themes for XS from XWiki SAS
by Vincent Massol 10 Dec '18

10 Dec '18

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

1 0

[xwiki-devs] [Proposal] Let contrib committers be JIRA administrators for contrib projects?
by Vincent Massol 09 Dec '18

09 Dec '18

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

3 5

[xwiki-devs] [XWiki Day] BFD#200
by Oana-Lavinia Florean 07 Dec '18

07 Dec '18

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

1 1

[xwiki-devs] [Proposal] Add a new xwiki/xwiki-jenkins-slave repository
by Vincent Massol 07 Dec '18

07 Dec '18

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

1 0