December 2015 - xwiki-devs@xwiki.org

[xwiki-devs] [Feedback] Evaluation of Travis as a CI tool
by Jean SIMARD 28 Jan '16

28 Jan '16

Dear devs, It's been a while I'm using Travis-CI.org as a CI tool for my projects. And I thought why not using it with XWiki? So I investigate a bit with xwiki/xwiki-commons [1]. If you don't want to read the details below, here is a resume. I would push to keep Jenkins at this point (much more complete than Travis) but, one killing-feature is missing (in my opinion): integration with Github (display the result of a build in Pull Request is of great value when evaluating a PR). The following list is not exhaustive and is mainly about the most important features I've noticed. ### Travis # Benefit * We don't maintain a server * It's well-integrated with Github * It builds Pull Requests * It builds Branches * UI is pretty nice (at least better than Jenkins, hey!) # Drawbacks * You cannot choose which branches you want to build (all or none) * The UI is crashing often on Firefox (blocks the browser for few seconds before Firefox propose to kill the script) * You only have a raw log (meaning Travis cannot present information of the log with a organised structure) ### Jenkins # Benefits * We already have it and it works * It's specifically adapted for Java project (much much more details to parse the result of the build logs) * It can build branches * It can build Pull Requests # Drawbacks * Consumes a lot of resources on our servers * UI is not easy to browse (note that it show much more than Travis so of course, it's more difficult to do an UI with more information!) [1] https://travis-ci.org/woshilapin/xwiki-commons/ -- Jean Simard jean.simard(a)xwiki.com Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org

3 2

[xwiki-devs] [Proposal] XWiki Core
by vincent＠massol.net 21 Jan '16

21 Jan '16

Hi committers (and devs in general), I’m submitting to you this idea, to try to improve the xwiki open source project and to give it a new dynamism. I believe the topics discussed below are made even more important since we’re soon going to develop the notion of flavors in XWiki. Note that this proposal obsoletes the http://markmail.org/message/4hglttljiio5v2km proposal (i.e. the move of some extensions in the xwiki github organization), which itself was obsoleting http://markmail.org/message/ppw2slpgqou2ihai Issues to solve =============== * The scope of the code maintained by the XWiki Dev Team (== the xwiki github organization) is increasing but the team stays relatively small * The more stuff we move into the repos of the xwiki github organization, the less easy it is for non-“XWiki Dev Team” committers to participate and we want more contributions Proposed solution ================= Executive summary: * Reduce the scope of all the code located in the xwiki github organization by only keeping “core” modules * A “core" module is defined by being a generic transversal module (i.e. that can be used in lots of XWiki flavors, if not all). This is opposed to “vertical” modules which are modules specific of a usage of XWiki. ** Examples of “core" modules: logging module, configuration module, distribution wizard, statistics application, annotations, active installs, one base flavor (the “XWiki” flavor), etc ** Example of “vertical” modules: meeting manager application, blog application, FAQ application, flavors (except the base flavor), etc Some consequences: * We need a new location for several modules that would go out of the xwiki github organization repos * It would be good to separate sandbox extensions from 1st class extensions that are maintained and developed following best practices. We need some way to maintain the quality of important extensions Detailed Implementation: * The “xwiki” github organization’s description becomes “XWiki Core” (it’s too complex to rename the org to “xwiki-core” IMO) * “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in there are called “XWiki Core Committers”). * “xwiki-contrib” is split into 2 github organizations (technically we rename it to “xwiki-contrib-sandbox”): ** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed extensions or abandoned extensions are located ** “xwiki-contrib-extensions”, where maintained extensions are located. * These 2 organizations are commonly referred to as “XWiki Contrib" * Same as now, anyone requesting a repo in xwiki-contrib-sandbox would be granted one and he/she’d be given write access to all repos in the xwiki-contrib-sandbox organization. * We define some rules for graduating from xwiki-contrib-sandbox to xwiki-contrib-extensions. For example: ** The extension should have been in xwiki-contrib-sandbox at least 6 months (this gives time to see if the extension is maintained during that time and will survive the test of time - most extensions will die in the first months) ** The extension should have had more than 2 releases and be published on extensions.xwiki.org(http://extensions.xwiki.org) with documentation ** The extension should work with the latest LTS version of XWiki + the latest stable version of XWiki (right now that would be 5.4.5 + 6.3). Note that if the extension has to use new API it’s ok that it doesn’t work on the latest LTS. ** Generally follow the practices defined at http://dev.xwiki.org * Each extension in xwiki-extensions has a leader/maintainer. He/she’s the one proposing to move the extension from xwiki-sandbox to xwiki-extensions. He/she’s responsible for ensuring that the extension gets regular releases and is maintained in general. He/she defines initially the list of committers in his email proposal for moving the extension. * We create a PMC (Project Management Committee) for XWiki Contrib, generally in charge of both xwiki-contrib-sandbox and xwiki-contrib-extensions (voting new extensions in xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I would send a mail on devs@ asking who’s interested to be part of this committee. I expect some core committers + some contrib committers to stand up. * Contrib extensions keep using the org.xwiki.contrib package name and groupid as currently defined at http://contrib.xwiki.org Note: The idea is that xwiki core is developed as a team maintaining all code in there, xwiki contrib is developed extension by extension (each extension is an island). This allows anyone to propose extensions in XWiki Contrib without the need for everyone to support them. WDYT? Thanks -Vincent

8 24

[xwiki-devs] [VOTE] Retire Colibri skin
by Thomas Mortagne 12 Jan '16

12 Jan '16

Hi devs, Following http://markmail.org/message/fb2tsh2gwu44xsua (Drop support for Colibri Skin in 7.x) I would like to propose to move colibri to https://github.com/xwiki-contrib/ in 8.0 branch. Here is my +1, -- Thomas Mortagne

7 14

[xwiki-devs] [Proposal] Bundle a Dashboard Gadget with Apps as a best practice
by vincent＠massol.net 12 Jan '16

12 Jan '16

Hi devs, On http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… we list some app dev best practices. I’m proposing to add one more bullet point which is that apps bundle one or several (but at least one) Dashboard Gadget (technically a Macro) so that users can easily add a view of the app on the home page (in their dashboard). For example: * FAQ app already provides a {{faq}} gadget to list all entries for a given FAQ app * Index app already provides a {{document}} gadget to list all documents matching some criteria * Blog app doesn’t currently provide such a gadget (it provides a velocity macro but that’s not a gadget) * Forum app should provide a {{forums}} gadget too to list all forums and a {{forum}} one to list entries from a given forum * etc WDYT? Thanks -Vincent

7 7

[xwiki-devs] [VOTE] Stop bundling the Statistics Application by default in XE
by Vincent Massol 08 Jan '16

08 Jan '16

Hi devs, Since statistics are disabled by default, I'm proposing to not bundle the Statistics application by default. Admins who want to enable stats on their would need to install it through the EM. In addition, the Stats app's quality is not exactly perfect either and performances are not that great so I think it makes sense to not promote it too much either. Last, since 5.3M2 the stats app is now visible in the Applications Panel (for Admins), thus not bundling it by default seems even more needed now IMO. WDYT? Thanks -Vincent

9 14

[xwiki-devs] [Idea] Deprecate terminal pages
by Guillaume Lerouge 06 Jan '16

06 Jan '16

Hi Devs, after trying XE 7.4 snapshot some more, I kept asking myself what was the point of even allowing terminal pages to exists. I couldn't see a good reason why any given page would *need* to be terminal, whereas it poses some issues: - There is no visual distinction between terminal pages and nested pages in the interface (besides "WebHome" in the URL, which would be cleaner to remove) - We're planning to make it possible to reference a nested page in wiki syntax without having to write "WebHome" in it - When creating a new page from a terminal page, you're creating a sibling instead of a child page, which breaks the user expectation (and the breadcrumb) - For AWM applications, data/content pages are created as terminal pages, which makes it impossible to add further content underneath them in the future (say, sub-tasks that would go as child pages of tasks) - To my knowledge, there is no easy way to transform a terminal page into a nested page should the need arise later on - However, I don't see any problem from a page being a nested page instead of being a terminal page In summary: why bother with terminal pages at all? I understand they're an artefact from our pre-nested-spaces model, but do they really make sense now? We could let existing terminal pages live on, but not remove the ability to create new ones even for admins. Am I missing something obvious? Thanks, Guillaume

6 18

[xwiki-devs] [Proposal] Adding Blockers systematically to release notes?
by vincent＠massol.net 05 Jan '16

05 Jan '16

Hi devs, I’d like to suggest a new best practice which would consist in systematically adding blockers issues in the release notes corresponding to the affects versions, at the top, using an error macro. For example I’ve updated the release notes for 7.2 and 7.3: - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki72 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki73 The idea would be to update our Release Notes template to automatically list them using this template snippet (example for XWiki 7.2): " {{error}} The following blocking issues were found after this version was released. You should verify if you're using the affected features and if so, you can click on them to see in which version they are fixed): {{jira url="http://jira.xwiki.org" style="list" source="jql"}} category = "Top Level Projects" and affectedVersion in ("7.2-milestone-1", "7.2-milestone-2", "7.2-milestone-3", "7.2-rc-1", "7.2") and fixVersion > "7.2" and priority = Blocker and resolution = Fixed {{/jira}} {{/error}} “ The goal is to make it easy for our end users to see blocking issues in a given release. The goal is also to make it visible to us how many blockers we introduce in each release and work on reducing this number as much as possible. WDYT? Thanks -Vincent

5 14

[xwiki-devs] [Proposal] Don't bundle the WebDAV feature by default in XE
by vincent＠massol.net 04 Jan '16

04 Jan '16

Hi Devs, Following our direction of making XWiki smaller and removing all non-core extensions from the XWiki runtime, I’d like to propose to remove the WebDAV feature by default in XE. Users would still be able to install it half-manually (the EM could install part of it but XWiki would need a restart so that the Container takes into account Servlet 3.0 servlets and filters). WDYT? Thanks -Vincent

6 5

[xwiki-devs] [VOTE] Move xwiki/1.0 old rendering framework to contrib
by Thomas Mortagne 04 Jan '16

04 Jan '16

Following the work done on http://jira.xwiki.org/browse/XWIKI-12001 to make the old rendering engine (xwiki/1.0 syntax based renderer) installable as extension I would like to propose to move it to https://github.com/xwiki-contrib/ in 8.0 branch. WDYT ? Here is my +1 -- Thomas Mortagne

6 5

[xwiki-devs] [Contrib] Check the PR on the video macro
by Mohamed Boussaa 31 Dec '15

31 Dec '15

Hello devs, I created a PR on the Video macro ( https://github.com/xwiki-contrib/macro-video) I added the possibility to play Dynamic Adaptive Streaming over HTTP (DASH) videos. I invite you to check the PR because I am working on a project that depends on this PR changes. https://github.com/xwiki-contrib/macro-video/pull/3 Thanks, Mohamed

1 0