xwiki-devs February 2011

xwiki-devs@xwiki.org

30 participants
95 discussions

[xwiki-devs] [Discussion] JIRA: Improving QA/Test Reports + relaxing JIRA rule

by Vincent Massol

Hi devs, Sorin and Silvia are helping us in term of improving the quality of platform/XE/XEM by systematically testing milestones/RCs/final versions. They've started a TestReports space on xwiki.org where he's going to put all his test reports from now on: http://www.xwiki.org/xwiki/bin/view/TestReports/ In those reports, when a test fails they'll need to create a JIRA issue (instead of pointing to a page on the incubator). This would make it much easier for reporting purpose, to see all the issues they've created and for us to see all issues found by the Q&A team. The problem is that our current JIRA strategy is to NOT create jira issue for issues that haven't been "released" already (instead the strategy is to comment in them). I'm proposing to relax this rule in the following manner: * Allow to have "affects" and "fix for" be the same value in JIRA * Automatically exclude from our release notes issues where "affects" == "fixfor" In addition IMO it would be good for Sorin/Silvia to: * Link the newly created jira to an existing jira WDYT? Thanks -Vincent

13 years, 8 months

[xwiki-devs] [VOTE] Add Document.getPlainTitle()

by Vincent Massol

Hi devs, In lots of places we need to display the title without any markup rendering. Examples: - breadcrumb - activity stream - search results etc This is such a common use case I'm proposing to add a new API for it in Document: getPlainTitle() It's a one liner that will do: getRenderedTitle("plain/1.0") Here's my +1 Thanks -Vincent

13 years, 8 months

[xwiki-devs] [VOTE] Move filesystem attachment storage into the core.

by Caleb James DeLisle

I would like to move the attachment storage code into the trunk for testing and inclusion in 3.0. I would like to put it in /core/xwiki-store/ which can begin the modularization of the storage engine. The filesystem attachment storage is still a work in progress but the main attachment storage class runs. I have added a new type of lock which automatically breaks deadlock and might solve the problem with deletion sometimes blocking. This code depends on and includes: TransactionRunnable which will allow us to evaluate TR in real life situations. Serialization apis for including a refactoring of the existing XMLWriter. File save/delete TransactionRunnables which serve as primitives for safe file saving and deletion on the filesystem. Lock manager which is still brand new and has to be moved into it's own package yet. An EntityReferenceSerializer for getting file paths from document names. This code provides: FilesystemAttachmentStore which is beta and functional. FilesystemAttachmentVersioningStore which is alpha and "you're on your own". along with compatible FilesystemAttachmentContent and ListAttachmentArchive. Here is my +1 for including this in the core so it can be developed and tested in concert. Caleb

13 years, 8 months

Re: [xwiki-devs] [Proposal] Making "Edit this attachment" an advanced feature in the advanced edit mode

by Raluca Stavro

Hello, >Sergiu Dumitriu wrote: > >>Silvia Rusu wrote: >> >>Hi devs, >> >>I propose we make "Edit this attachment" in the "Attachments" tab an advanced feature in the advanced edit mode. >> >>When trying to use "Edit this attachment": - in IE you get the following message: "Could not initialize a required ActiveX object" - in FF 3.5.2 installing the extension delivers the following message:"FoxWiki 1.0b could not be installed because it is not compatible with Firefox 3.5.2". - installing the extension on an older version of FF requires additional configuration, which the average user may not know how to perform. >> Under the above circumstances I think "Edit this attachment" will cause confusion for the average user instead of providing a useful tool. >> >>WDYT? >> > >Agreed to remove the edit button if the FF extension is not already installed and configured. The edit button is still there and the Firefox extension can't be installed because it is not compatible with newer Firefox versions. I really think that we should remove this button as soon as possible because this is a non-functionality at this point. Raluca.

13 years, 8 months

[xwiki-devs] [VOTE] Release IRCBot 1.0 application

by Vincent Massol

Hi devs, Just realized we've never released it. I'm proposing to do it today and document it at http://extensions.xwiki.org/xwiki/bin/view/Extension/IRC+Bot+Application Here's my +1 Thanks -Vincent

13 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs February 2011