- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Proposal] Move Stats-related code to a new xwiki-platform-statistics-api module
by vincent＠massol.net 11 Jan '16

11 Jan '16

Hi devs, I’d like to move all stats-related code to a new module under xwiki-platform-statistics. It’s not very easy since there are (scripting) APIs in XWiki and Document classes. So I propose the following: Step 1: * Deprecate all APIs related to stats in oldcore (XWiki, Document, XWikiStatService, XWikiStatsServiceImpl) and move them to oldcore legacy. * Modify XWikiStatsServiceImpl to not implement EventListener anymore * Move all other code from com.xpn.xwiki.stats.* in xwiki-platform-statistics-api, under an org.xwiki.stats package (and refactor XWikiStatsServiceImpl to use them) * Create a new StatisticsManager (if you have a better name, shoot! StatisticsAccess? StatisticsReader?) component in xwiki-platform-statistics-api and copy all the APIs from XWikiStatService (removing XWikiContext ofc). Note that the goal here is to make this simple and fast and not to redo a stats module with a different API... * Add a new stats script service in xwiki-platform-statistics-api (accessed through: $services.stats.*). It’d be a copy of the stats-related APIs currently in Document * Add a new EventListener in xwiki-platform-statistics-api, copying the Event-related code from XWikiStatsServiceImpl. This is the code that saves stats in the DB. Step 2: * Modify the Stats App to use the new script service Step 3: * Introduce a new Admin UI for activating/disabling stats (see http://jira.xwiki.org/browse/XWIKI-7919) WDYT? Thanks -Vincent

1 0

[xwiki-devs] [Proposal] Dates for XWiki 8.x Cycle
by vincent＠massol.net 09 Jan '16

09 Jan '16

Hi devs, I’m proposing the following dates for the 8.x cycle: * 8.0: March 2016 (currently planned for mid-march) * 8.1: May 2016 * 8.2: July 2016 * 8.3: September 2016 * 8.4: November 2016 Note that for 2015, we did the following: * 7.0: March 2015 (/) * 7.1: --May 2015-- June 2015 (/) * 7.2: --July 2015-- September 2015 (/) * 7.3: --September 2015-- November 2015 (/) * 7.4: --November 2015-- December 2015 (/) The reason I’m keeping the original dates of 7.x for 8.x is: * to ensure that we are able to finish 8.x by the end of 2016. * to try to have the 8.x cycle finished before the christmas holidays so that we could work on 8.4.x during the last weeks of December and have a fully finished cycle before we start 9.0 in Jan 2017, as otherwise the N.4.x bugfix releases are eating a lot of time from the N+1.0 release. Also note that 7.2 was delayed a lot because of Nested Spaces. WDYT? Thanks -Vincent

5 4

[xwiki-devs] {Proposa|] Roadmap for XWiki 8.0
by vincent＠massol.net 09 Jan '16

09 Jan '16

Hi devs, Here are some proposals below that I have discussed with committers from XWiki SAS already. For all other committers (thinking about Denis, Sergiu, Clemens, or others), feel free to add other stuff you’d like to do in 8.0. Content ======= Priority 1: * Polish the CKEditor integration and bring it up to par with our current WYSIWYG editor with the goal of replacing our current editor in XWiki 8.1. - Marius * Polish/finish the Nested Spaces topics (migrations, leftovers). Needed in 7.4.1 and 7.4.2. See bit.ly/1ORc8zD - GuillaumeD for the migrations, everyone for the rest. * Continue improving upgrade tools: Scriptable upgrades (priority 1), Simulation (priority 2), others - Edy * Finish Flavor mechanism + provide Platform Flavor + minimalistic XWiki distribution - Thomas * Improved xwiki.org: better download and install pages, improved style, etc - Caty * Define new UI Extension points - Caty Priority 2 (if priority 1 items are finished): * MediaWiki Import - Thomas * Better notifications: live notifications (when a forum post is added, when a comment is posted), app-related AS events, other - Edy Proposed Dates ============== * 8.0M1: 25 Jan 2016 * 8.0M2: 15 Feb 2016 * 8.0RC1: 29 Feb 2016 * 8.0Final: 14 Mar 2016 WDYT? Thanks -Vincent

5 5

[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

Re: [xwiki-devs] Help needed to get statitics from old xwiki into new one
by Nigel COUTIN 06 Jan '16

06 Jan '16

Hi to all xwiki devs and users, First of all best wishes and happy new year. We have a problem to get statistics from a standalone xwiki 7.1.2 (hsql + jetty) into a new version xwiki entreprise 7.4 (postgre + tomcat).As we have seen on the support site the import/export fonctions do not include statitics… Is there a possiblity to do so and how could it be done? Thank in advance for your replies Nigel COUTIN Le Mercredi 6 janvier 2016 9h37, Nigel COUTIN <coutin_nigel(a)yahoo.fr> a écrit : Hi to all xwiki devs and users, First of all best wishes and happy new year. We have a problem to get statistics from a standalone xwiki 7.1.2(hsql + jetty) into a new version xwiki entreprise 7.4 (postgre + tomcat).As we have seen on the support site the import/exportfonctions do not include statitics… Is there a possiblity to do so and how could it be done? Thank in advance for your replies Nigel COUTIN

1 0

Re: [xwiki-devs] [Proposal] Keep old LTS till next version N.4.1 is released
by Thomas Mortagne 05 Jan '16

05 Jan '16

In my understanding the rule is supposed to be 3 supported branches (dev, stable, lts) so I guess we can say until 8.0 is released 7.4.x is just the stable branch (and 6.4.x the lts). We pretty much always have the same conversation every time we start a new major version branch. On Mon, Jan 4, 2016 at 9:46 AM, vincent(a)massol.net <vincent(a)massol.net> wrote: > Hi devs, > > I see on http://enterprise.xwiki.org/xwiki/bin/view/Main/Download that the new LTS is 7.4. > > I think that’s a bit dangerous because LTS means that users can put it in production with eyes closed and we’re guaranteeing stability. In practice it’s a bit too early to decide if 7.4 is really that stable. > > In the future I’d suggest that we wait till 7.4.1 (i.e. N.4.1) is released because we remove the previous LTS and swap it with the new one. > > WDYT? > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne

6 8

Re: [xwiki-devs] [Proposal] Keep old LTS till next version N.4.1 is released
by Eduard Moraru 05 Jan '16

05 Jan '16

+1 for proposal 2. Thanks, Eduard On Tue, Jan 5, 2016 at 4:23 AM, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote: > +1 for proposal 2. > > On 01/04/2016 03:46 AM, vincent(a)massol.net wrote: > > Hi devs, > > > > I see on http://enterprise.xwiki.org/xwiki/bin/view/Main/Download that > the new LTS is 7.4. > > > > I think that’s a bit dangerous because LTS means that users can put it > in production with eyes closed and we’re guaranteeing stability. In > practice it’s a bit too early to decide if 7.4 is really that stable. > > > > In the future I’d suggest that we wait till 7.4.1 (i.e. N.4.1) is > released because we remove the previous LTS and swap it with the new one. > > > > WDYT? > > > > Thanks > > -Vincent > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

1 0

[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] Keep old LTS till next version N.4.1 is released
by vincent＠massol.net 05 Jan '16

05 Jan '16

Hi devs, I see on http://enterprise.xwiki.org/xwiki/bin/view/Main/Download that the new LTS is 7.4. I think that’s a bit dangerous because LTS means that users can put it in production with eyes closed and we’re guaranteeing stability. In practice it’s a bit too early to decide if 7.4 is really that stable. In the future I’d suggest that we wait till 7.4.1 (i.e. N.4.1) is released because we remove the previous LTS and swap it with the new one. WDYT? Thanks -Vincent

2 1