xwiki-devs January 2012

xwiki-devs@xwiki.org

28 participants
61 discussions

[xwiki-devs] [Discussion] Release strategy and slippages - Timeboxing

by Vincent Massol

Hi devs, We've been quite bad at following the release strategy we've defined so far: timeboxing. We've been constantly slipping our release dates during all the past releases (and not by 1 or 2 days, but by 2 weeks or more). Personally I find this not professional of us and for me it means that the date we give are just a joke now. I don't even see why we're giving dates since they can only be misleading to anyone who would act on them… At the current slippage rate, we should only give a month estimation to have a chance of being correct ;) There's only one reason we're really slipping IMO: we've forgotten that we're doing time boxing. Let me remind us what time boxing is and how it can be made to work: * It means releasing on a fixed date and releasing whatever is ready at that date. * The idea is also to do quick releases so that if a given feature is not in a release it'll be in the next one coming soon (we used to do 2 to 3 weeks releases at some points and recently we've been doing instead 3-5 weeks instead) * The reason for releasing often is because this pushes the bug fixes and new stuff to users ASAP and thus let them experiment with them and give us feedback (bugs, usability, etc) * The way to make timeboxing work is by having automated functional tests so that we can release safely knowing that our test suite will catch the problems if any. This means that whenever a commit is done, in the same commit there are tests proving that what is committed is working (and not several weeks later which would be anti-timeboxing). * it doesn't mean we cannot have a roadmap. What it means is that we should the maximum of what is in the roadmap in a given time slot. What's not done doesn't get released. This means that large features should be divided into small one that will fit. Developers need to think about what they're doing by constantly checking the release date and verifying what they can achieve for that date and make absolutely sure that what they have committed is working for that date (even if what they have committed is not finished). * Timeboxing is not about how many men/days you have available or whether people are on holidays or not. If you have less men/days you do less work. It doesn't change the release date. Basically you can only do timeboxing if you have good and automated quality control. The opposite of timeboxing is feature releases which lead to the following: * People committing not working stuff or without tests because they know they'll have time to fix it later on before the release (easy to think this since there's no release date, it's only when the features are done that it'll get released) * Release date become not important since they keep being pushed since what's important is to release planned features * Build failing all the time and developers not caring about it ("it can always be fixed later when we get close to the release date" - that's easy to say since there' no fixed release date) * Users seeing less frequent releases and giving less feedback to developers (thus helping less) * In general, quality dropping over time So we have several choices: 1) Forget timeboxing and do feature-based releases, i.e. we list features and we only release when they're done 2) Start doing real timeboxing again I've seen so many projects do 1) in the past with such bad results that for me there's no doubt that the only good strategy is 2). Especially for an open source project which has a strong community and we should be releasing stuff regularly and quickly to this community to get good feedback. Doing timeboxing is also a great way to improve the quality of our code. Timeboxing can only work fine if everyone agrees with it (we can revert stuff from a developer if it breaks things but it's a pain) and believe in the release date, so we'd need everyone's agreements. So WDYT, are we ok to resume doing timeboxing and go back on track? On my side I'm ok to do it and help enforce it. If we agree we should start now by releasing RC1 ASAP and give a new date for 3.4 final and release on that date. Thanks -Vincent

12 years, 7 months

[xwiki-devs] [Vote] Release 3.4RC1 ASAP (today/tomorrow) ?

by Marius Dumitru Florea

Hi devs, What do you prefer: (1) Release 3.4RC1 today or tomorrow (depending on how much time it takes to fix the failing tests on CI and any blockers -- please list them) and release 3.4 final this Thursday, 19 January. (2) Release 3.4RC1 at the end of this week (Thursday/Friday) and release 3.4 final at the start of the next week, 23 January. I'm more for (2) because it would allow me to include some fixes to the AppWithinMinutes that I couldn't do in 3.4M1 because I was busy with fixing failing tests on CI, doing the actual release and writing the release notes. Thanks, Marius

12 years, 7 months

[xwiki-devs] List of users property in a class within a workspace

by Ido Meshi

12 years, 7 months

[xwiki-devs] Fwd: Happy to announce the creation of XWiki Clams Core + XClams Wiki

by Ludovic Dubost

News on XWiki CLAMS (Curriki) ---------- Forwarded message ---------- From: Ludovic Dubost <ludovic(a)xwiki.com> Date: 2012/1/14 Subject: Happy to announce the creation of XWiki Clams Core + XClams Wiki To: xclams-devs(a)xwiki.org Hi, I'm happy to announce that the migration process from SVN to GitHub and creation of the XClams and Curriki.org project went very well. We know have: https://github.com/xwiki-contrib/xwiki-clams-core with the curriki-2.0, curriki-2.1 and the master branch https://github.com/xwiki-contrib/currikiorg with the curriki 1.8 and older branches The Sankore source code will come soon We also have: A brand new Wiki: http://xclams.xwiki.org with more information about the project, the community and the committers I've also published the current velocity APIs in the current xwiki-clams-core: http://xclams.xwiki.org/xwiki/bin/view/Design/XClamsVelocityAPIsV22 The next steps are: - the publishing of the Sankore Source Code - changing the jenkins build to the GitHub source - bringing back many patches from Sankore into xwiki-clams-core - create the xwiki-clams-demo project with clean default data for a XClams based project - bring back Curriki.org on the master branch Thanks a lot to Sergiu for his help Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 7 months

[xwiki-devs] XCLAMS mailing list on markmail

by Ludovic Dubost

Hi, The migration of Curriki to XClams is progressing. Thanks to Sergiu we now have the xclams-core and currikiorg projects on GitHub. Thanks Sergiu. I'm currently working on preparing xclams.xwiki.org. While doing that, I think it would be nice to archive the xclams-dev mailing list on markmail and nabble. I'm not sure how to do that. I'm sure Vincent can help ? Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 7 months

[xwiki-devs] XWiki Enterprise and XWiki Enterprise Manager 3.4 Milestone 1 Released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.4 Milestone 1. This is the first and only milestone of the 3.4 version. We're getting closer to the end of the 3.x cycle and the goal of this release (and the following one, which will be the last of the cycle) is to improve the current features. The highlights of this release are: * New default color theme * XWiki 2.1 is the default page syntax * Delete space menu * Simple space templates * Special characters in attachment name * Minimized action menu * Display macro * Improved Extension Manager UI See the full release notes at http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… for more details. Thanks -The XWiki dev team

12 years, 7 months

[xwiki-devs] Get current space [velocity]

by Hamster

This should be easy, but I am stuck :-( I have created a new panel. The panel shows all the document in the current space. But if the user is in the Main Space, I don't want to show any documents, I want to show all the spaces (except for a couple default spaces). #if $currentSpace = "Main" #set ($hiddenSpaces = ["AnnotationCode", "ColorThemes", "Invitation", "Panels", "Scheduler", "Stats", "XWiki"]) #set($spacesSorted=$xwiki.sort($xwiki.spaces) ) #foreach($space in $spacesSorted) #if (!$hiddenSpaces.contains($space)) * [[$space>>${space}.WebHome]] #end #end #else // Code which shows all documents #end How do I know when I am in the Main Space? -- View this message in context: http://xwiki.475771.n2.nabble.com/Get-current-space-velocity-tp7183403p7183… Sent from the XWiki- Dev mailing list archive at Nabble.com.

12 years, 7 months

[xwiki-devs] [VOTE] Remove existing deprecated ColorThemes and replaced them with new ones for XE 3.4

by Ecaterina Moraru (Valica)

Hi devs, Since the recent Skin/ColorThemes changes done for XE 3.4, the existing ColorThemes are deprecated. I propose to remove them from our standard distribution and replace them with some themes created specially for the new skin changes. You can see these 3 new colorthemes (Ruby, Dusk, Mint) at: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/34NewColorThemes (clicking on the preview image you can see them in action) obs. I created a ColorTheme for every color we have in XWiki logo (blue, orange, red, green) The deprecated ColorThemes will still be available in the extensions repository: Default http://extensions.xwiki.org/xwiki/bin/view/Extension/Default33+ColorTheme Bordo http://extensions.xwiki.org/xwiki/bin/view/Extension/Bordo+ColorTheme Nature http://extensions.xwiki.org/xwiki/bin/view/Extension/Nature+ColorTheme BlueSky http://extensions.xwiki.org/xwiki/bin/view/Extension/BlueSky+ColorTheme Inner Dark http://extensions.xwiki.org/xwiki/bin/view/Extension/Inner+Dark+ColorTheme Nightfall http://extensions.xwiki.org/xwiki/bin/view/Extension/Nightfall+ColorTheme Peach http://extensions.xwiki.org/xwiki/bin/view/Extension/Peach+ColorTheme This is my +1 Pull request at https://github.com/xwiki/xwiki-enterprise/pull/14 waiting for the vote result and will be committed for 3.4 RC1. Thanks, Caty

12 years, 8 months

[xwiki-devs] [VOTE] Change document id stored in the database to reduce the likelihood of duplicate id

by Denis Gervalle

Now that the database migration mechanism has been improved, I would like to go ahead with my patch to improve document ids. Currently, ids are simple string hashcode of a locally serialized document reference, including the language for translated documents. The likelihood of having duplicates with the string hashing algorithm of java is really high. What I propose is: 1) use an MD5 hashing which is particularly good at distributing. 2) truncate the hash to the first 64bits, since the XWD_ID column is a 64bit long. 3) use a better string representation as the source of hashing Based on previous discussion, point 1) and 2) has already been agreed, and this vote is in particular about the string used for 3). I propose it in 2 steps: 1) before locale are fully supported in document reference, use this format: <lengthOfLastSpaceName>:<lastSpaceName><lengthOfDocumentName>:<documentName><lengthOfLanguage>:<language> where language would be an empty string for the default document, so it would look like 7:mySpace5:myDoc0: and its french translation could be 7:mySpace5:myDoc2:fr 2) when locale are included in reference, we will replace the implementation by a reference serializer that would produce the same kind of representation, but that will include all spaces (not only the last one), to be prepared for the future. While doing so, I also propose to fix the cache key issue by using the same reference, but prefixed by <lengthOfWikiName>:<wikiName>, so the previous examples will have the following key in the document cache: 5:xwiki7:mySpace5:myDoc0: and 5:xwiki7:mySpace5:myDoc2:fr Using such a key (compared to the usual serialization) has the following advantages: - ensure uniqueness of the reference without requiring a complex escaping algorithm, which is unneeded here. - potentially reversible - faster than the usual serialization - support language - independent of the current serialization that may evolved independently, so it will be stable over time which is really important when it is used as a base for the hashing algorithm used for document ids stored in the database. I would like to introduce this as early as possible, which means has soon has we are confident with the migration mechanism recently introduced. Since the migration of ids will convert 32bits hashes into 64bits ones, the risk of collision is really low, and to be careful, I have written a migration algorithm that would support such collision (unless it cause a circular reference collision, but this is really unexpected). However, changing ids again later, if we change our mind, will be really more risky and the migration difficult to implements, so it is really important that we agree on the way we compute these ids, once for all. Here is my +1, -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

12 years, 8 months

[xwiki-devs] [VOTE] New {{display}} macro and changes to the {{include}} macro

by Vincent Massol

Hi devs, As you know in XE 3.0 we've changed the behavior for resolving local links/attachments when they're included using the {{include}} macro (they're now resolved against the included document instead of the including document). Now there might be some use cases (pretty rare IMO but they exist) where you'd want the links to be resolved against the including document. Here's a use case: you have a sheet document that references an image called image.png and you want that the including document provides it (like an Abstract in Java! ;)). So we've brainstormed with Thomas and here's our proposal: * Introduce a new {{display reference="…"/}} macro. This macro will *execute* the passed reference in its own context (it'll do what {{include context="new"…}} was doing before). It'll be located in the new display module. * Deprecate the "context" parameter of the {{include}} macro. The reason is that calling with context=new is not an include, it's a display. * Add a new "resolve" parameter for the {{include}} macro with possible values = "current" | "source", with a default value of "source". resolve=source means that the links/attachments are resolved against the source (ie the document being included). Using resolve=current means that you want the links/attachments resolved against the including document. Pros: * Clearly separate the 2 use cases: display and include * Make the include macro simple (a single "resolve" parameter) * Use the new display module as it should be and start the direction of having displayer macros for displaying all types of entities Note: In the future we'll also want to deprecate the "document" parameter of the include macro in favor of a more generic "reference" parameter, which will allow the macro to include other types of entities (such as an object property for ex). WDYT? Here's my +1 Thanks -Vincent

12 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 January 2012