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
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
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
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
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
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
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
+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
>
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
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