xwiki-devs March 2018

xwiki-devs@xwiki.org

15 participants
38 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, 1 month

[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, 6 months

[xwiki-devs] [VOTE] Add new check to measure quality of tests

by Vincent Massol

Hi devs, As part of the STAMP research project, we’ve developed a new tool (Descartes, based on Pitest) to measure the quality of tests. It generates a mutation score for your tests, defining how good the tests are. Technical Descartes performs some extreme mutations on the code under test (e.g. remove content of void methods, return true for methods returning a boolean, etc - See https://github.com/STAMP-project/pitest-descartes). If the test continues to pass then it means it’s not killing the mutant and thus its mutation score decreases. So in short: * Jacoco/Clover: measure how much of the code is tested * Pitest/Descartes: measure how good the tests are Both provide a percentage value. I’m proposing to compute the current mutation scores for xwiki-commons and xwiki-rendering and fail the build when new code is added that reduce the mutation score threshold (exactly the same as our jacoco threshold and strategy). I consider this is an experiment to push the limit of software engineering a bit further. I don’t know how well it’ll work or not. I propose to do the work and test this for over 2-3 months and see how well it works or not. At that time we can then decide whether it works or not (i.e whether the gains it brings are more important than the problems it causes). Here’s my +1 to try this out. Some links: * pitest: http://pitest.org/ * descartes: https://github.com/STAMP-project/pitest-descartes * http://massol.myxwiki.org/xwiki/bin/view/Blog/ControllingTestQuality * http://massol.myxwiki.org/xwiki/bin/view/Blog/MutationTestingDescartes If you’re curious, you can see a screenshot of a mutation score report at http://massol.myxwiki.org/xwiki/bin/download/Blog/MutationTestingDescartes/… Please cast your votes. Thanks -Vincent

6 years, 4 months

[xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector

by Claude Brisson

Hi. I'm currently working on Velocity 2.0 packaging. If that's OK with you, I would like to incorporate DeprecatedCheckUberspector.java into Velocity, but I need a statement from your part to be able to change its licence to Apache 2.0 (LGPL and Apache 2.0 licences aren't compatible). By the way, I take this opportunity to tell you that if there is another specific part of xwiki-commons-velocity that you think should be integrated on our side, or an important missing feature you'd like to insist on, don't hesitate. I already integrated VELOCITY-825, for instance, so String->Enum constant conversions are now handled by Velocity. There may be other important conversion cases you'd like to see handled. Regards, Claude

6 years, 4 months

[xwiki-devs] [Vote] Assignee for PR: Contributor or Committer?

by Ecaterina Moraru (Valica)

Hi, We have discussed this subject multiple times, but we don't have an official vote and conclusion on the topic. Problem: In JIRA who is the Assignee of an issue fixed by a Pull Request? 1: Contributor - he provided the solution - giving the attributions, the contributor might feel encouraged to contribute more - we could do some JIRA statistics on external contributions, but this use case can be covered by GitHub statistics 2: Committer - he does the merging on his account and he becomes responsible for the committed code. - in case there are problems, the committer needs to find solution, since we can't rely on contributors availability - in doing the PR review, the committer spends a lot of time analyzing and testing the provided solution We are talking here about complete solutions provided by the PR, since in case of partial solutions, the committer can assign himself on the issue (depends on the quantity of modification he does). Let me know what you think, Caty

6 years, 6 months

[xwiki-devs] [Proposal] e.x.o improvements: grid, icons, colors

by Ecaterina Moraru (Valica)

Hi devs, Here are some ideas about how the repository application used on extensions.xwiki.org could look like if we were to provide multiple display layouts for extensions, require the contributors to add custom icons, colors and screenshots. http://design.xwiki.org/xwiki/bin/view/Proposal/exoGrid In terms of design I tried to make it look as a proper application store, but it will be heavily influenced on users providing ratings for extensions and contributors on providing quality icons / colors/ description / screenshots. In terms of interaction, the biggest change would be a revamp of the search functionality. Currently users are using it, but it's a generic search, focused on text results. Let me know what you think, Caty P.S. Proposal ideas iterated with Marius, Alex and Eduard.

6 years, 7 months

[xwiki-devs] Please review my proposal!

by Vivek Iyer

Hi everyone! I've made my proposal for the blockly editor and since the deadline is tonight (India time) it would be great if this could be reviewed ASAP! The link for my proposal is: https://docs.google.com/document/d/1oKmfXGZnxVSGnShkIZ8irfuX4qhR1br3LtKczmc… Thanking you, Regards, Vivek Iyer

6 years, 7 months

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

by Alex Cotiugă

Hello devs, This Thursday is BFD#171: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status is: * -47 bugs over 120 days (4 months), i.e. we need to close 47 bugs to have created bugs # = closed bugs # * -96 bugs over 365 days (1 year) * -111 bugs over 500 days (between 1 and 2 years) * -313 bugs over 1600 days (4.3 years) * -720 bugs since the beginning of XWiki See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#171 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14093 Happy Bug Fixing Day, Alex

6 years, 7 months

[xwiki-devs] Add a REST API to XWiki Notifications

by nikos delis

Hi all, I am new on this mailist and thanks for the invite.I have do proposal for Add a Rest API to XWiki Notifications. mr Clément Aubin came into contact with me with some helpful links to understand how notifications is impliment on Xwiki platform and how notifications works.I see that you have a complete Notificaton API that works perfect for Xwiki platform therefore you want to make a REST API to take notifications from other platforms to Xwiki platform? I understood this from the speech .Second REST API will be created from scratch? or will build up on the existing? Thanks for reading Nikos.

6 years, 7 months

[xwiki-devs] [ANN] XWiki 9.11.4 released

by Alex Cotiugă

The XWiki development team is proud to announce the availability of XWiki 9.11.4. This is a bugfix release that covers important issues that we have discovered since 9.11.3 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.4/ Thanks for your support -The XWiki dev team

6 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 March 2018