November 2014 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] Have extension repositories in the "xwiki" GitHub Organization
by vincent＠massol.net 17 Nov '14

17 Nov '14

Hi devs, Following the proposal thread at http://markmail.org/message/ppw2slpgqou2ihai I’d like to move on and I’ve prepared below a full proposal that I’d like us to VOTE on. Rationale/Need =============== The needs: * Be able to extract some apps from xwiki-contrib that the XWiki Dev Team would like to maintain. Example: File Manager app developed by Marius when it’ll have had some releases and tests (if it doesn’t have some already!), GitHub Stats app used on xwiki.org, Meeting Manager App, Forum App, etc * Be able to extract some extensions currently located in xwiki-platform but not released with XE so that they can have a different release cycle (examples: FAQ app, IRCBot extension, JIRA macro, etc). Having different release cycle allow to release new versions quicker to our users (bug fixes, new features). Governance ========== Details: * Extensions are VOTEd in on a case by case basis. * Each voted extensions will have its own Git Repository in the “xwiki” organization (so that each extension can be released independently of each other). * When moving an extension either from xwiki-contrib or from xwiki-platform, keep its Git history as much as possible or simply donate the repo to the “xwiki" organization. * FTM extensions bundled by default with XE would still remain in XWiki Commons/Rendering/Platform/Enterprise. * The Git repository name should be of the form xwiki-<short project name>. <short project name> should be part of the VOTE. * All rules from http://dev.xwiki.org apply * Each extension has a Release Manager defined and he’s responsible for defining its own Roadmap/Release notes (if need be), on the extension page on e.x.o and perform the releases or ensure the extension is released regularly when there are changes. * Each extension must follow these criteria for being VOTEd: ** A Release Manager needs to be defined in the proposal ** The extension must have had several releases already (i.e. someone wanting to propose a new extensions that doesn’t exist would start in xwiki-contrib for ex and prove that his extension works and is useful by doing several releases and creating the pages on e.x.o) ** It must follow our best practices defined on http://dev.xwiki.org (coding practices, tests, etc) and follow the apps best practices (for apps), see http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… ** It must have one or several integration or functional tests (for apps) to prove that it works. This allows to prove the app continues working when XWiki progresses ** The main contributors of the extensions must agree about the move. If they have the “level" to be an xwiki dev committer then they should be voted in (see http://dev.xwiki.org/xwiki/bin/view/Community/Committership) If not then either they’re ok to send Pull Requests or the extension should not be moved. * If an extension ceases to work or if its quality becomes too low, it can be moved to xwiki-contrib with a VOTE * We would create one JIRA project per extension * We would create a new JIRA Category called “XWiki Extensions” * We would put the extensions in our CI at http://ci.xwiki.org * The Java package should follow the same rule as for XWiki Platform, i.e. org.xwiki.<short project name>. Exceptions would need to be discussed. * The group id for extensions having their own repo should be org.xwiki.<short project name>. The <short project name> needs to be part of the VOTE when proposing a new extensions. Here’s my +1 Thanks -Vincent

9 16

[xwiki-devs] [Apps] What is the minimum XWiki version we should depend on /support for the Apps we are reviewing / redesigning?
by Ecaterina Moraru (Valica) 17 Nov '14

17 Nov '14

Hi, Since 6.3 roadmap we are working on improving a set of applications from Contrib, read more on http://design.xwiki.org/xwiki/bin/view/Proposal/CollaborativeApplications The purpose of the improvement is to make sure they work on the new skin and also that they have an unitary style. We have some design proposals for Calendar, Forum, Meeting and Task. For example this is how the Task app should look like http://design.xwiki.org/xwiki/bin/download/Proposal/TaskApplicationDesign/t… Problems: A. We are tempted to use (and already started using in some cases) CSS classes from Bootstrap (Flamingo). Here we can enumerate: grid classes, responsive classes, specific BS classes (buttons, labels, etc.). For some of these classes we have some partial equivalent classes in Colibri (.half, .third, .button, etc.) so even if it will not look perfect in Colibri, the app will be displayed. // Flamingo is available since XWiki 6.2 B. Also the image I've just shown is using some icons. We are tempted to use Icon Themes variables, this way the app will be able to adapt to any given IconTheme. // IconThemes is available since XWiki 6.3 C. The apps we are reviewing are still using '$msg.get' we would like to replace that with the new $services.localization // Localization Macro is available since XWiki 4.3 D. Other deprecated calls, depends on the app. The problem is that some apps now have defined the parent version as 4.1, 4.3, 6.2, etc. and might not be a true statement anymore, and the version needs to be updated. Is it ok for the new redesign applications to use new api and be dependent of newer versions of XWiki? This way we can make sure we are creating great looking apps and using the latest functionality for the new versions of the app. In our case that would be 6.3. The downside of this is that you won't be able to upgrade your apps to this new versions we are improving, without migrating/updating your entire wiki. Should we depend on a smaller version? WDTY? Thanks, Caty

4 5

[xwiki-devs] [XWiki Day] BFD#70
by Eduard Moraru 14 Nov '14

14 Nov '14

Hi devs, As you probably already know, today is BFD#70: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 81 bugs behind. See: http://jira.xwiki .org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-Resolved-Chart/10470 We have started getting a bit of an edge in our struggle, but we need to keep this up otherwise we`ll lose it again. Here's the BFD#69 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12702 Thanks and enjoy your bug fixing day! -Eduard

1 1

[xwiki-devs] [Proposal] Capitalization rules
by vincent＠massol.net 12 Nov '14

12 Nov '14

Hi devs, Andrea created an issue about capitalizing button labels (http://jira.xwiki.org/browse/XWIKI-11265) and I think it’s a good idea that we decide some rules about capitalization indeed. I’ve found this document from MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/bb246428(v=vs.85).a… I propose to adopt this document’s content as our rule for Capitalization and to document that in our dev best practices on dev.xwiki.org. Example of labels: * “Add comment” —> “Add Comment” * “Reset to default” —> “Reset to Default” WDYT? Thanks -Vincent

8 26

[xwiki-devs] [Discussion] Make XWiki Case Insensitive. WDYT?
by Eduard Moraru 12 Nov '14

12 Nov '14

Hi users and devs, I would like to have your opinion on the topic of case sensitive vs case insensitive and which one you prefer in XWiki. Currently, XWiki is case sensitive. This means the same resource name (document name, space name, etc) can be written with either small letters or big letters or a mix. Examples: You can have both "Main.Test" and "Main.test" as 2 different documents. Also, you can have "XWiki.Admin" and "XWiki.admin" as 2 different users. This also applies to URLs, as "/Main/Test" is different from "/Main/test" or "/main/test", so all these 3 are different resources. Even from this short description, one can already identify possible problems of this approach. >From the top 3 operating systems (Linux, Mac an Windows), only Linux is case sensitive, the other two (more user-focused Operating Systems) are both case insensitive. Since XWiki has one of its main targets the Enterprise users, it is safe to assume that the correct approach would be to also be more user-focused and simplify things and avoid confusions by being case insensitive as well. Also, a quick search on existing issues validates the need for this improvement: http://jira.xwiki.org/issues/?jql=text%20~%20%22case%20insensitive%22 What do you think? Is it OK to keep XWiki case sensitive, or would you prefer it case insensitive? Bring arguments. I have also created a jira issue for this idea: http://jira.xwiki.org/browse/XWIKI-11412 to track it in the future. Thanks, Eduard

6 16

[xwiki-devs] [ANN] XWiki 6.3 released
by Guillaume "Louis-Marie" Delhumeau 12 Nov '14

12 Nov '14

The XWiki development team is proud to announce the availability of XWiki 6.3. This release provides a great stabilization of the Flamingo Skin, and includes new themes and some improvements to manage them. It also contains a new mail API and module to replace the old mailsender plugin, a new dynamic tree widget that is progressively replacing all existing trees in XWiki (Document Index, Navigation Panels, etc...), some improvements on the Extension Manager as well as on the User Directory and the Applications Panel. Efforts have been made on the performances side, with good results on view mode (except on the first loaded-page). We reach the same performances as 5.4.6, which was not the case during the 6.x cycle until now. This is a first milestone to get even better! Finally, and like every releases, a lot of bugs have been fixed. 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/ReleaseNotesXWiki63 Thanks -The XWiki dev team

1 0

[xwiki-devs] [Contrib] Repository request
by Paul Pantiru 12 Nov '14

12 Nov '14

Hello, May I request a new repository named "xwiki-application-multiselectsuggest" for an upgraded version of this <http://extensions.xwiki.org/xwiki/bin/view/Extension/Multiselect+custom+dis…>extension(the first version did not have a repo on xwiki-contrib nor was it released on maven)? Description: A custom suggest displayer for DBList object properties which adapts the suggest feature to multiple selection. It will soon be updated on extensions.xwiki.org as well. GitHub username: ppantiru Thanks, Paul P.

2 1

[xwiki-devs] [Proposal] Release 6.3 final on the 12th
by vincent＠massol.net 11 Nov '14

11 Nov '14

Hi devs, I’m currently releasing 6.2.4. Since we’ve just released 6.3RC1 at the end of last week I propose to delay the 6.3 final release by 2 days, i.e. that we release it on Wednesday the 12th. This should give us 2 more days to fix any potential issue in it. During these 2 days we should make sure to not merge any dangerous changes obviously since the build is passing fine for 6.3 rigth now ;) WDYT? Thanks -Vincent

4 3

[xwiki-devs] [ANN] XWiki 6.2.4 released
by vincent＠massol.net 10 Nov '14

10 Nov '14

The XWiki development team is proud to announce the availability of XWiki 6.2.4. In addition to being a bugfix release, this release adds a new Application to manage Flamingo Themes. 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/ReleaseNotesXWiki624 Thanks -The XWiki dev team

1 0

[xwiki-devs] Home Page - Use cases, proposals, what we have until now and what we want to achieve
by Eduard Moraru 10 Nov '14

10 Nov '14

Hi devs, We have already had some discussions recently on how we can improve XWiki's homepage. After talking to Vincent in private, we have decided to come up with a set of use cases/goals[1] that we want to have/achieve with the improvement of the homepage so that we make sure that we all speak the same language and consider all use cases when proposing something. On the same page as the use cases[1], you have a link below for the existing proposals[2] and each proposal that was discussed until now (I added one too) is listed and compared to the use cases it had to cover. Please have a look and tell us what you think about the use cases and the analysis of each proposal. This is not yet a vote, but just an attempt to get everybody on the same boat in terms of expectations. Thanks, Eduard ---------- [1] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageUseCases [2] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposals

7 22