xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

by Vincent Massol

Hi devs, The story: * Some reporter (Anca in this case) reported the issue https://jira.xwiki.org/browse/XWIKI-13947 as a bug * Caty modified it as an improvement * I didn’t quite agree and also consider it to be a bug So I think it would be healthy that we agree about the difference of bug vs improvement. This is not meant as a flamewar but more as a discussion to see if we could reach an agreement. If not, then so be it, we won’t have a common agreement. Here’s my POV and what I consider a bug is: "A bug is something that was NOT wanted by the developer. It's not related to its severity and there can be minor bugs and important bugs” I realize that another definition could be “A bug is any behaviour that a user consider not normal” but I find this more hazy and subject to interpretation so I prefer my first definition. For Caty a bug is “[…]broken/not working behaviour.” but that definition is not precise enough IMO since for me the issue in XWIKI-13947 is a broken behavior (I consider that the right behavior is to have the same top and bottom margin for boxes) and thus would match Caty’s rule. I also consider that there can be all types of bugs: visual bugs, performance bugs, feature bugs, etc and thus I don’t consider that visual issues are always improvements and never bugs. So an improvement would be about doing something differently than in the way it was voluntarily implemented. WDYT? Thanks -Vincent

7 years, 11 months

[xwiki-devs] [Proposal] New threshold for BFD (#135)

by Alexandru Cotiuga

Hi devs, Today is BFD#135: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays As the goals described in http://markmail.org/message/v3jb64dw3e6e4mut (0 difference between resolved and created bugs for 1600 and 365 periods) have been achieved and there are still bugs to be fixed, I propose a new goal of achieving the same result for a 500 days period. Starting BFD#15 we can monitor our current status for the 500 days period, which is 28 bugs behind: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352#Created-vs-R… And the dashboard to follow the progress during today's BFD is: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13801 Enjoy you BugFixing Day, Alex

7 years, 11 months

[xwiki-devs] [ANN] XWiki 9.0 released

by Eduard Moraru

The XWiki development team is proud to announce the availability of XWiki 9.0. This release marks the start of the 9.x cycle and features mostly developer and admin feature improvements. The most notable ones are the improved handling of big attachments, filesystem Recycle Bin and CK Editor improvements. 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.0 Thanks for your support -The XWiki dev team

7 years, 11 months

[xwiki-devs] [XWiki Day] Test Day #1

by Thomas Mortagne

Hi devs, Since nobody really answered the proposal until very late last week here it is: The idea today is to do a Test Day with priority to fixing long standing flickering (integration mostly) tests. You can find known flickering tests on http://jira.xwiki.org/issues/?filter=14240. The goal is to really fix them, not just add some random wait here and there ;) If you are really not confident with the area around those specific flickering tests here are some other ideas for this kind of Day: * obviously add more tests and increase the code coverage * move tests from enterprise to platform. Needed for the platform flavor and removal of XE * update jacoco covering setup (we often forget to increase it when adding more tests) * move more tests from JMock to Mockito * work on new test setups and tools: ** improve docker containers for packaging XWiki (possibly several for multiple DBs and Servlet containers). ** work on spreading Jenkins platform job into one job per maven module so that build can be spread on various agents (groovy scripting) ** Research/Use Jenkins 2 Pipeline plugin with the new DSL and commit the jenkinsfile in SCM ** Test platform to run contrib extension tests on various versions of XWiki automatically * Speedup existing tests (research xwiki startup time, remove unnecessary modules, etc) When what you fix can be linked to an issue, tag it with "testday" (same idea as "bugfixingday" when doing BFD). If not then answer to this mail to explain what you did. Good Test Day ! -- Thomas Mortagne

7 years, 11 months

Re: [xwiki-devs] [Proposal] Changing the location of XED files

by Denis Gervalle

Sorry if my question looks late or stupid, but what is the benefit of those xed files, how are they added to the lib folder currently ? That might explains why these meta information are not integrated to the jar file, what I would have expected more than B. Thanks, -- Denis Gervalle SOFTEC sa - CEO On Fri, Jan 27, 2017 at 3:07 PM, Denis Gervalle <denis.gervalle(a)softec.lu> wrote: Sorry if my question looks late or stupid, but what is the benefit of those xed files, how are they added to the lib folder currently ? That might explains why these meta information are not integrated to the jar file, what I would have expected more than B. Thanks, -- Denis Gervalle SOFTEC sa - CEO On Wed, Jan 25, 2017 at 9:31 PM, Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> wrote: I don't have a problem with keeping the XED files in WEB-INF/lib if the spec doesn't forbid it, especially if it simplifies the implementation. Thanks, Marius On Tue, Jan 24, 2017 at 2:26 PM, Vincent Massol <vincent(a)massol.net> wrote: > Hi devs, > > In XWiki 9.0RC1 we’re putting XED files in WEB-INF/lib next to the JAR to > which they correspond. > > I have 2 issues with this: > * We’re not really supposed to use WEB-INF/lib for that. WEB-INF/lib is > meant for JAR files that are to be made available to the classloader. It’s > even possible that some servlet container would emit warnings about this. > * This is a WTF for admins when they discover this. The WAR has a spec and > it’s standardised. Thus the WTF when you see this since you’re not used to > seeing this anywhere else. > > I’m thus proposing to move the XED files to a META-INF/xwiki/ directory > inside the WAR instead since META-INF is meant to contain metadata > information and is thus meant exactly for this. > > WDTY? > > Thanks > -Vincent > >

7 years, 11 months

[xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

by Vincent Massol

Hi devs, We have plenty of existing limitations in our PDF export (table autoresize, etc) which comes from FOP and our usage of it. And it’s hard to improve it. I’d like to propose the following: * Promote the browser’s print to PDF feature instead of our PDF Export by triggering the browser’s print feature when clicking on Export > PDF in the UI. * Work on our print.css so that it has all the styles we have in view mode (right now for ex, info boxes for ex do not have a nice style). * Move our PDF Export java code out of xwiki-platform and into an optional extension that we move into xwiki-contrib. The use case for it would be when you need to generate PDF from scripts. WDYT? Thanks -Vincent

7 years, 11 months

[xwiki-devs] [ANN] XWiki 9.0 Release Candidate 1 released

by Guillaume Delhumeau

The XWiki development team is proud to announce the availability of XWiki 9.0 Release Candidate 1. This version opens the new 9.x cycle. It contains all improvements introduced in versions 8.4.1 to 8.4.4, and brings admin and developer features mostly. Among other things, XWiki deals better with big attachments now. 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.0RC1/ Thanks for your support -The XWiki dev team

7 years, 11 months

[xwiki-devs] [VOTE] Move all Confuence related modules to contrib

by Thomas Mortagne

Hi devs, I would like to give Confluence filter input and syntaxes modules there own life on xwiki-contrib pretty much on the same model than what I did for MediaWiki (https://github.com/xwiki-contrib/mediawiki/) since it's exactly the same use case. The main reasons are: * those modules are not embedded (for the input) or enabled (for the syntaxes) by default * those modules need to follow Confluence evolution more than XWiki WDYT ? Here is my +1 -- Thomas Mortagne

7 years, 11 months

[xwiki-devs] [Proposal] Changing the location of XED files

by Vincent Massol

Hi devs, In XWiki 9.0RC1 we’re putting XED files in WEB-INF/lib next to the JAR to which they correspond. I have 2 issues with this: * We’re not really supposed to use WEB-INF/lib for that. WEB-INF/lib is meant for JAR files that are to be made available to the classloader. It’s even possible that some servlet container would emit warnings about this. * This is a WTF for admins when they discover this. The WAR has a spec and it’s standardised. Thus the WTF when you see this since you’re not used to seeing this anywhere else. I’m thus proposing to move the XED files to a META-INF/xwiki/ directory inside the WAR instead since META-INF is meant to contain metadata information and is thus meant exactly for this. WDTY? Thanks -Vincent

7 years, 11 months

[xwiki-devs] [Proposal] New Best Practice for closing issues as Duplicate

by Manuel Smeria

Hello Devs, I would like to propose a new best practice for the way we close issues as Duplicate. As an example I've reported this issue: http://jira.xwiki.org/browse/XWIKI-13728 which was later closed as a Duplicate to http://jira.xwiki.org/browse/XWIKI-13729. >From my perspective, this is not correct since the issue I reported is valid from an user's POV. I would have preferred that my issue was renamed and that developers would have added some technical information as a comment to it if they wanted to do so. It just doesn't make any sense to me to close a perfectly valid issue as a Duplicate just to create another one that has a more technically correct summary and description. It also doesn't make sense to close the original issue as a Duplicate to a duplicate issue :) (pun intended) I see things like this: my issue's description is a use-case of the issue later reported by Edy, so if anything, Edy's issue should be closed as a Duplicate to mine and not the other way around. One scenario where I think issues dated previously should be closed as Duplicate is if the new issue has already been fixed. For example when a Developer doesn't notice an older issue and starts working on the new one instead of closing the new one as a Duplicate and work on the older one. There might be more, feel free to add them to this thread. So, what I propose is that we don't close original issues as Duplicate unless it falls into the category previously described or some other exceptions that I can't think of now and might occur. Thanks, Manuel

7 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs