On 06 Jun 2016, at 14:50, Marius Dumitru Florea <[email protected]> wrote:

On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < [email protected]> wrote:

...

Hello all,

As it was decided already, a Homepage Tour have to be implemented. However, no option regarding the place where the Tour Application should be added as dependency was discussed.

There are some possible options: 1) XWiki Enterprise 2) XWiki Platform Distribution 3) XWiki Platform Helper

4) Is there any option to have the Tour Application as a part of the Core ?

What would be the best way to include the Contrib applications in XWiki?

On this topic (sorry if I hijack your thread) I was wondering why don't we have dependencies from platform/enterprise to contrib. We have lots of third party dependencies, contrib could be considered as such. Moreover, we're in the process of moving non-core (vertical) extensions out of platform to contrib. It would be a pity to move something from contrib to platform and then back to contrib. I have the same issue with the CKEditor Integration extension. We want CKEditor as the default editor, bundled with the default distribution, but do we need to move it to platform? Same for the Welcome Tour.

I’d personally not like this for the following reasons: 1) I like that the XWiki runtime is all released at once with all extensions making it using the same versions and verified to work together. 2) Support. The XWiki runtime is supported by the XWiki Core Dev Team. Extensions in contrib are not supported by the XWiki Core Dev Team. In addition xwiki-contrib is very open and anyone can make modifications there and quality is thus harder to guarantee. We defined the xwiki github organization as containing horizontal modules, ie modules that can be required for any flavor and both CKEditor and the Tour Application fit the need. By opposition to vertical modules which make sense only for some use cases (like the Meeting Manager app) and not by default in XE. We have the option of having flavors in contrib for those if we want though. For CKEditor it’s not a good thing since we’d like it by default. One alternative (which I’m not fond of at all) would be to have ckeditor as a separate git repo in the xwiki github organization. Thanks -Vincent

Thanks, Marius

...

Thanks, Alex

On 06 Jun 2016, at 15:24, Marius Dumitru Florea <[email protected]> wrote:

On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol <[email protected]> wrote:

...

...

On 06 Jun 2016, at 14:50, Marius Dumitru Florea < [email protected]> wrote:

On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < [email protected]> wrote:

...

Hello all,

As it was decided already, a Homepage Tour have to be implemented. However, no option regarding the place where the Tour Application should be added as dependency was discussed.

There are some possible options: 1) XWiki Enterprise 2) XWiki Platform Distribution 3) XWiki Platform Helper

4) Is there any option to have the Tour Application as a part of the Core ?

What would be the best way to include the Contrib applications in XWiki?

On this topic (sorry if I hijack your thread) I was wondering why don't we have dependencies from platform/enterprise to contrib. We have lots of third party dependencies, contrib could be considered as such. Moreover, we're in the process of moving non-core (vertical) extensions out of platform to contrib. It would be a pity to move something from contrib to platform and then back to contrib. I have the same issue with the CKEditor Integration extension. We want CKEditor as the default editor, bundled with the default distribution, but do we need to move it to platform? Same for the Welcome Tour.

I’d personally not like this for the following reasons:

...

1) I like that the XWiki runtime is all released at once with all extensions making it using the same versions and verified to work together.

XWiki runtime has lots of third party dependencies. Bootstrap, Solr, jQuery, just to name a few. I don't see how having the source code in our repo (platform) makes a difference at runtime when the integration/functional tests verify they work together.

Because they don’t! :) Just check any extension in contrib and you’ll see their func test (when they have some!) don’t test that they work with the latest version of XWiki…

2) Support. The XWiki runtime is supported by the XWiki Core Dev Team.

...

Extensions in contrib are not supported by the XWiki Core Dev Team.

So the FAQ application you moved out of platform is no longer supported by the XWiki Core Dev Team?

Correct.

The extension page http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application doesn't reflect this.

I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” because it's a past authors and it wouldn’t make sense to remove it. But yes it’s no longer officially supported by the XWiki Core Dev Team. Note that e.x.o doesn’t say who maintains a given extension, it just says who participated to developing it ;) We’re currently missing the info on whether the extension is actively supported and by whom. FTR Confluence does this with a “supported” label that you can hover over and provides info. For example: https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number... Thanks -Vincent

In addition xwiki-contrib is very open and anyone can make modifications

...

there and quality is thus harder to guarantee.

We defined the xwiki github organization as containing horizontal modules, ie modules that can be required for any flavor and both CKEditor and the Tour Application fit the need. By opposition to vertical modules which make sense only for some use cases (like the Meeting Manager app) and not by default in XE. We have the option of having flavors in contrib for those if we want though. For CKEditor it’s not a good thing since we’d like it by default.

One alternative (which I’m not fond of at all) would be to have ckeditor as a separate git repo in the xwiki github organization.

Thanks -Vincent

...

Thanks, Marius

...

Thanks, Alex

On 07 Jun 2016, at 09:37, Guillaume Delhumeau <[email protected]> wrote:

Moving Tour Application into platform makes sense to me (it becomes a critical component and deserves a proper support).

For me, it’s really about the definition of what the XWiki github org represents. Right now with the new strategy == “Everything needed for the default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling XE so far but that we’ll slim down a bit, for example by removing the Blog app and move it to contrib). Now we could still decide to have some flavor in contrib and have the tour app included in that flavor but not in “the default XWiki runtime”. In practice this would mean promoting this flavor instead of the base/default flavor. The question will arise anyway when we next talk about other flavors that we may want to have in contrib such a KB flavor, workgroup flavor, web flavor, etc.

However, the current application supports XWiki >= 6.4.1. By moving it to platform, we will only support the last XWiki version.

This is a tough topic indeed. For the tour there’s the solution of keeping it in contrib and introducing a flavor but for CKEditor it’s harder to justify that it’s not part of the base flavor IMO but maybe it’s possible and we would offer only the wiki editor in the base flavor. Of course we could modify our functional tests fwk to support running on various versions of the dependencies and have CI builds to ensure that an extension works with all versions but it’s not perfect and it would mean that for the first time we would have code in the xwiki github org that would not use the latest APIs/latest JDK features. The other option is Marius’s, i.e. accept that we hand-pick some extensions from contrib that we bundle in the base/default flavor such as the Tour app, CKEditor integration, etc. In this case, we would just need to redefine what “xwiki github org” means. Saying “core component” would not be enough, it would needs a more precise definition. Interesting topic ;) Any other option that we have? Thanks -Vincent

2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>:

...

...

On 06 Jun 2016, at 15:24, Marius Dumitru Florea < [email protected]> wrote:

On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol <[email protected]> wrote:

...

...

On 06 Jun 2016, at 14:50, Marius Dumitru Florea < [email protected]> wrote:

On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < [email protected]> wrote:

...

Hello all,

As it was decided already, a Homepage Tour have to be implemented. However, no option regarding the place where the Tour Application should be added as dependency was discussed.

There are some possible options: 1) XWiki Enterprise 2) XWiki Platform Distribution 3) XWiki Platform Helper

4) Is there any option to have the Tour Application as a part of the Core ?

What would be the best way to include the Contrib applications in

XWiki?

...

...

...

On this topic (sorry if I hijack your thread) I was wondering why don't we have dependencies from platform/enterprise to contrib. We have lots of third party dependencies, contrib could be considered as such. Moreover, we're in the process of moving non-core (vertical) extensions out of platform to contrib. It would be a pity to move something from contrib to platform and then back to contrib. I have the same issue with the CKEditor Integration extension. We want CKEditor as the default editor, bundled with the default distribution, but do we need to move it to platform? Same for the Welcome Tour.

I’d personally not like this for the following reasons:

...

1) I like that the XWiki runtime is all released at once with all extensions making it using the same versions and verified to work together.

XWiki runtime has lots of third party dependencies. Bootstrap, Solr, jQuery, just to name a few. I don't see how having the source code in our repo (platform) makes a difference at runtime when the integration/functional tests verify they work together.

Because they don’t! :) Just check any extension in contrib and you’ll see their func test (when they have some!) don’t test that they work with the latest version of XWiki…

...

2) Support. The XWiki runtime is supported by the XWiki Core Dev Team.

...

Extensions in contrib are not supported by the XWiki Core Dev Team.

So the FAQ application you moved out of platform is no longer supported by the XWiki Core Dev Team?

Correct.

...

The extension page http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application doesn't reflect this.

I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” because it's a past authors and it wouldn’t make sense to remove it. But yes it’s no longer officially supported by the XWiki Core Dev Team.

Note that e.x.o doesn’t say who maintains a given extension, it just says who participated to developing it ;) We’re currently missing the info on whether the extension is actively supported and by whom. FTR Confluence does this with a “supported” label that you can hover over and provides info. For example: https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

Thanks -Vincent

...

In addition xwiki-contrib is very open and anyone can make modifications

...

there and quality is thus harder to guarantee.

We defined the xwiki github organization as containing horizontal modules, ie modules that can be required for any flavor and both CKEditor and the Tour Application fit the need. By opposition to vertical modules which make sense only for some use cases (like the Meeting Manager app) and not by default in XE. We have the option of having flavors in contrib for those if we want though. For CKEditor it’s not a good thing since we’d like it by default.

One alternative (which I’m not fond of at all) would be to have ckeditor as a separate git repo in the xwiki github organization.

Thanks -Vincent

...

Thanks, Marius

...

Thanks, Alex

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Marius,

On 07 Jun 2016, at 11:17, Marius Dumitru Florea <[email protected]> wrote:

On Tue, Jun 7, 2016 at 11:27 AM, Vincent Massol <[email protected]> wrote:

...

...

On 07 Jun 2016, at 09:37, Guillaume Delhumeau < [email protected]> wrote:

Moving Tour Application into platform makes sense to me (it becomes a critical component and deserves a proper support).

...

For me, it’s really about the definition of what the XWiki github org represents. Right now with the new strategy == “Everything needed for the default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling XE so far but that we’ll slim down a bit, for example by removing the Blog app and move it to contrib).

"Everything needed for the default XWiki runtime" is a bit vague.

Yes indeed; it’s very precise for the existing XE (which is well-defined) but doesn’t say anything about future. A better definition is what we defined in the "xwiki core” thread (source: http://markmail.org/message/w6veilqhhnjqcw3e): " 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, 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 " According to this definition the Tour and CKEditor are both core modules. Related threads: - Move rendering extensions out: http://markmail.org/message/y3bkch37mt5iwvxu - Terminology: http://markmail.org/message/hl4xwdxwpi7gnia2 - Move platform extensions out: http://markmail.org/message/viesrhmdavyvdaec - XWiki Core - Take 3: http://markmail.org/message/w6veilqhhnjqcw3e

I hope we're not going to move code from platform to contrib and back each time we decide to not bundle or bundle some extension.

That’s the idea and what you voted on, see for example: - Move rendering extensions out: http://markmail.org/message/y3bkch37mt5iwvxu - Move platform extensions out: http://markmail.org/message/viesrhmdavyvdaec Thanks -Vincent

Now we could still decide to have some flavor in contrib and have the tour

...

app included in that flavor but not in “the default XWiki runtime”. In practice this would mean promoting this flavor instead of the base/default flavor. The question will arise anyway when we next talk about other flavors that we may want to have in contrib such a KB flavor, workgroup flavor, web flavor, etc.

...

However, the current application supports XWiki >= 6.4.1. By moving it to platform, we will only support the last XWiki version.

This is a tough topic indeed. For the tour there’s the solution of keeping it in contrib and introducing a flavor but for CKEditor it’s harder to justify that it’s not part of the base flavor IMO but maybe it’s possible and we would offer only the wiki editor in the base flavor. Of course we could modify our functional tests fwk to support running on various versions of the dependencies and have CI builds to ensure that an extension works with all versions but it’s not perfect and it would mean that for the first time we would have code in the xwiki github org that would not use the latest APIs/latest JDK features.

The other option is Marius’s, i.e. accept that we hand-pick some extensions from contrib that we bundle in the base/default flavor such as the Tour app, CKEditor integration, etc. In this case, we would just need to redefine what “xwiki github org” means. Saying “core component” would not be enough, it would needs a more precise definition.

Interesting topic ;)

Any other option that we have?

Thanks -Vincent

...

2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>:

...

...

On 06 Jun 2016, at 15:24, Marius Dumitru Florea < [email protected]> wrote:

On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol <[email protected]> wrote:

...

> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < [email protected]> wrote: > > On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < > [email protected]> wrote: > >> Hello all, >> >> As it was decided already, a Homepage Tour have to be implemented. However, >> no option regarding the place where the Tour Application should be added as >> dependency was discussed. >> >> There are some possible options: >> 1) XWiki Enterprise >> 2) XWiki Platform Distribution >> 3) XWiki Platform Helper >> >> 4) Is there any option to have the Tour Application as a part of the Core ? >> >> What would be the best way to include the Contrib applications in

XWiki?

...

>> > > On this topic (sorry if I hijack your thread) I was wondering why

don't

...

...

...

we > have dependencies from platform/enterprise to contrib. We have lots of > third party dependencies, contrib could be considered as such. Moreover, > we're in the process of moving non-core (vertical) extensions out of > platform to contrib. It would be a pity to move something from contrib to > platform and then back to contrib. I have the same issue with the CKEditor > Integration extension. We want CKEditor as the default editor, bundled with > the default distribution, but do we need to move it to platform? Same for > the Welcome Tour.

I’d personally not like this for the following reasons:

...

1) I like that the XWiki runtime is all released at once with all extensions making it using the same versions and verified to work together.

XWiki runtime has lots of third party dependencies. Bootstrap, Solr, jQuery, just to name a few. I don't see how having the source code in our repo (platform) makes a difference at runtime when the integration/functional tests verify they work together.

Because they don’t! :) Just check any extension in contrib and you’ll see their func test (when they have some!) don’t test that they work with the latest version of XWiki…

...

2) Support. The XWiki runtime is supported by the XWiki Core Dev Team.

...

Extensions in contrib are not supported by the XWiki Core Dev Team.

So the FAQ application you moved out of platform is no longer supported by the XWiki Core Dev Team?

Correct.

...

The extension page http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application doesn't reflect this.

I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” because it's a past authors and it wouldn’t make sense to remove it. But yes it’s no longer officially supported by the XWiki Core Dev Team.

Note that e.x.o doesn’t say who maintains a given extension, it just says who participated to developing it ;) We’re currently missing the info on whether the extension is actively supported and by whom. FTR Confluence does this with a “supported” label that you can hover over and provides info. For example:

https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

...

Thanks -Vincent

...

In addition xwiki-contrib is very open and anyone can make

modifications

...

...

...

there and quality is thus harder to guarantee.

We defined the xwiki github organization as containing horizontal modules, ie modules that can be required for any flavor and both CKEditor and the Tour Application fit the need. By opposition to vertical modules which make sense only for some use cases (like the Meeting Manager app) and not by default in XE. We have the option of having flavors in contrib for those if we want though. For CKEditor it’s not a good thing since we’d like it by default.

One alternative (which I’m not fond of at all) would be to have ckeditor as a separate git repo in the xwiki github organization.

Thanks -Vincent

> Thanks, > Marius > > >> >> Thanks, >> Alex

On 07 Jun 2016, at 11:36, Ecaterina Moraru (Valica) <[email protected]> wrote:

So the main concerns are: A. moving (changing history, ids, versioning scheme, version compatibility, etc.) B. commit rights & ownership C. support definition

What’s more important for me is D: what we want the xwiki github org to be (see my other mails before and after on this thread). Thanks -Vincent

A. Maybe in the future we might want to create flavors that contain community applications, without the need to move them somewhere (like Mocca Calendar for example). I don't like moving things around, losing history, breaking ids, versioning, etc. It is an interesting topic because in the past years, when we experimented something, we first committed code outside of platform. So the move topic will happen for other apps too.

B. Regarding commit rights, they can be set per repository. So we could indeed handpick apps and allow only committers to support them. Now this indeed implies changing some of our definitions and providing such a list of applications. Regarding ownership, I think preserving the initial owner of the app, gives the appropriate credits to him. From a community perspective I think is better for an app to be attribute to the initial committer, rather than switching the ownership to XWiki's Development Team.

C. Now the problem is the 'support', since as you said it's hard for as committers to offer support for apps that are not in platform. Changing the commit rights from contrib to committers could be a solution, if the owner agrees. Now IMO we can easily change the definition of what 'support' means, we only need motivation and to see additional benefits.

So I would: - ask the owner if he wants his app to be bundled by default - not move the app, just use as a dependency - ask if we can change the initial rights to allow committers + owner(s), instead of contrib. A note that for some apps, multiple people could be better suited to 'support' the app, rather than the committers group - ask the owner if he can 'support' the app. Bundling an app implies that the committers will support it, but additional owners can and should support it. If the owners would like to support the app, but they are not committers, I would not want us to be 'forced' to give commit rights just because we will need to move the app inside platform. Or for the owner to 'renounce' his app. - as part of the support agreement, request the app to have functional tests and have a job on ci.

So the other problems remaining are different version schemes, compatibility and the list of bundled contrib apps: - Compatibility will be better since you could install new versions of the app, on older versions of XE. Now the testing will be more problematic (in mixing different version). - Compatibility field on e.x.o needs to be updated on every XE release. This could mean increased work for the RM or the owner(s). - The list of bundled apps can be generated using the 'bundled' property we have on Repository app.

Anyway :) this implies some changes. I would like us not to move the app, but not sure how this will fully impact our current rules.

Thanks, Caty

On Tue, Jun 7, 2016 at 11:27 AM, Vincent Massol <[email protected]> wrote:

...

...

On 07 Jun 2016, at 09:37, Guillaume Delhumeau < [email protected]> wrote:

Moving Tour Application into platform makes sense to me (it becomes a critical component and deserves a proper support).

For me, it’s really about the definition of what the XWiki github org represents. Right now with the new strategy == “Everything needed for the default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling XE so far but that we’ll slim down a bit, for example by removing the Blog app and move it to contrib).

Now we could still decide to have some flavor in contrib and have the tour app included in that flavor but not in “the default XWiki runtime”. In practice this would mean promoting this flavor instead of the base/default flavor. The question will arise anyway when we next talk about other flavors that we may want to have in contrib such a KB flavor, workgroup flavor, web flavor, etc.

...

However, the current application supports XWiki >= 6.4.1. By moving it to platform, we will only support the last XWiki version.

This is a tough topic indeed. For the tour there’s the solution of keeping it in contrib and introducing a flavor but for CKEditor it’s harder to justify that it’s not part of the base flavor IMO but maybe it’s possible and we would offer only the wiki editor in the base flavor. Of course we could modify our functional tests fwk to support running on various versions of the dependencies and have CI builds to ensure that an extension works with all versions but it’s not perfect and it would mean that for the first time we would have code in the xwiki github org that would not use the latest APIs/latest JDK features.

The other option is Marius’s, i.e. accept that we hand-pick some extensions from contrib that we bundle in the base/default flavor such as the Tour app, CKEditor integration, etc. In this case, we would just need to redefine what “xwiki github org” means. Saying “core component” would not be enough, it would needs a more precise definition.

Interesting topic ;)

Any other option that we have?

Thanks -Vincent

...

2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>:

...

...

On 06 Jun 2016, at 15:24, Marius Dumitru Florea < [email protected]> wrote:

On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol <[email protected]> wrote:

...

> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < [email protected]> wrote: > > On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < > [email protected]> wrote: > >> Hello all, >> >> As it was decided already, a Homepage Tour have to be implemented. However, >> no option regarding the place where the Tour Application should be added as >> dependency was discussed. >> >> There are some possible options: >> 1) XWiki Enterprise >> 2) XWiki Platform Distribution >> 3) XWiki Platform Helper >> >> 4) Is there any option to have the Tour Application as a part of the Core ? >> >> What would be the best way to include the Contrib applications in

XWiki?

...

>> > > On this topic (sorry if I hijack your thread) I was wondering why

don't

...

...

...

we > have dependencies from platform/enterprise to contrib. We have lots of > third party dependencies, contrib could be considered as such. Moreover, > we're in the process of moving non-core (vertical) extensions out of > platform to contrib. It would be a pity to move something from contrib to > platform and then back to contrib. I have the same issue with the CKEditor > Integration extension. We want CKEditor as the default editor, bundled with > the default distribution, but do we need to move it to platform? Same for > the Welcome Tour.

I’d personally not like this for the following reasons:

...

1) I like that the XWiki runtime is all released at once with all extensions making it using the same versions and verified to work together.

XWiki runtime has lots of third party dependencies. Bootstrap, Solr, jQuery, just to name a few. I don't see how having the source code in our repo (platform) makes a difference at runtime when the integration/functional tests verify they work together.

Because they don’t! :) Just check any extension in contrib and you’ll see their func test (when they have some!) don’t test that they work with the latest version of XWiki…

...

2) Support. The XWiki runtime is supported by the XWiki Core Dev Team.

...

Extensions in contrib are not supported by the XWiki Core Dev Team.

So the FAQ application you moved out of platform is no longer supported by the XWiki Core Dev Team?

Correct.

...

The extension page http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application doesn't reflect this.

I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” because it's a past authors and it wouldn’t make sense to remove it. But yes it’s no longer officially supported by the XWiki Core Dev Team.

Note that e.x.o doesn’t say who maintains a given extension, it just says who participated to developing it ;) We’re currently missing the info on whether the extension is actively supported and by whom. FTR Confluence does this with a “supported” label that you can hover over and provides info. For example:

https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

...

Thanks -Vincent

...

In addition xwiki-contrib is very open and anyone can make

modifications

...

...

...

there and quality is thus harder to guarantee.

We defined the xwiki github organization as containing horizontal modules, ie modules that can be required for any flavor and both CKEditor and the Tour Application fit the need. By opposition to vertical modules which make sense only for some use cases (like the Meeting Manager app) and not by default in XE. We have the option of having flavors in contrib for those if we want though. For CKEditor it’s not a good thing since we’d like it by default.

One alternative (which I’m not fond of at all) would be to have ckeditor as a separate git repo in the xwiki github organization.

Thanks -Vincent

> Thanks, > Marius > > >> >> Thanks, >> Alex

On 07 Jun 2016, at 10:27, Vincent Massol <[email protected]> wrote:

...

On 07 Jun 2016, at 09:37, Guillaume Delhumeau <[email protected]> wrote:

Moving Tour Application into platform makes sense to me (it becomes a critical component and deserves a proper support).

For me, it’s really about the definition of what the XWiki github org represents. Right now with the new strategy == “Everything needed for the default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling XE so far but that we’ll slim down a bit, for example by removing the Blog app and move it to contrib).

Now we could still decide to have some flavor in contrib and have the tour app included in that flavor but not in “the default XWiki runtime”. In practice this would mean promoting this flavor instead of the base/default flavor. The question will arise anyway when we next talk about other flavors that we may want to have in contrib such a KB flavor, workgroup flavor, web flavor, etc.

...

However, the current application supports XWiki >= 6.4.1. By moving it to platform, we will only support the last XWiki version.

This is a tough topic indeed.

Actually in practice we would support not only the last XWiki version but also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we could (we still have a stable-6.4.x branch ATM that we were supposed to remove) but it would mean changing our support strategy to support more branches… and it means supporting the whole platform for 6.4.x, not just one extension… Thanks -Vincent

For the tour there’s the solution of keeping it in contrib and introducing a flavor but for CKEditor it’s harder to justify that it’s not part of the base flavor IMO but maybe it’s possible and we would offer only the wiki editor in the base flavor. Of course we could modify our functional tests fwk to support running on various versions of the dependencies and have CI builds to ensure that an extension works with all versions but it’s not perfect and it would mean that for the first time we would have code in the xwiki github org that would not use the latest APIs/latest JDK features.

The other option is Marius’s, i.e. accept that we hand-pick some extensions from contrib that we bundle in the base/default flavor such as the Tour app, CKEditor integration, etc. In this case, we would just need to redefine what “xwiki github org” means. Saying “core component” would not be enough, it would needs a more precise definition.

Interesting topic ;)

Any other option that we have?

Thanks -Vincent

...

2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>:

...

...

On 06 Jun 2016, at 15:24, Marius Dumitru Florea < [email protected]> wrote:

On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol <[email protected]> wrote:

...

...

On 06 Jun 2016, at 14:50, Marius Dumitru Florea < [email protected]> wrote:

On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < [email protected]> wrote:

> Hello all, > > As it was decided already, a Homepage Tour have to be implemented. However, > no option regarding the place where the Tour Application should be added as > dependency was discussed. > > There are some possible options: > 1) XWiki Enterprise > 2) XWiki Platform Distribution > 3) XWiki Platform Helper > > 4) Is there any option to have the Tour Application as a part of the Core ? > > What would be the best way to include the Contrib applications in

XWiki?

...

...

>

On this topic (sorry if I hijack your thread) I was wondering why don't we have dependencies from platform/enterprise to contrib. We have lots of third party dependencies, contrib could be considered as such. Moreover, we're in the process of moving non-core (vertical) extensions out of platform to contrib. It would be a pity to move something from contrib to platform and then back to contrib. I have the same issue with the CKEditor Integration extension. We want CKEditor as the default editor, bundled with the default distribution, but do we need to move it to platform? Same for the Welcome Tour.

I’d personally not like this for the following reasons:

...

1) I like that the XWiki runtime is all released at once with all extensions making it using the same versions and verified to work together.

XWiki runtime has lots of third party dependencies. Bootstrap, Solr, jQuery, just to name a few. I don't see how having the source code in our repo (platform) makes a difference at runtime when the integration/functional tests verify they work together.

Because they don’t! :) Just check any extension in contrib and you’ll see their func test (when they have some!) don’t test that they work with the latest version of XWiki…

...

2) Support. The XWiki runtime is supported by the XWiki Core Dev Team.

...

Extensions in contrib are not supported by the XWiki Core Dev Team.

So the FAQ application you moved out of platform is no longer supported by the XWiki Core Dev Team?

Correct.

...

The extension page http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application doesn't reflect this.

I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” because it's a past authors and it wouldn’t make sense to remove it. But yes it’s no longer officially supported by the XWiki Core Dev Team.

Note that e.x.o doesn’t say who maintains a given extension, it just says who participated to developing it ;) We’re currently missing the info on whether the extension is actively supported and by whom. FTR Confluence does this with a “supported” label that you can hover over and provides info. For example: https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

Thanks -Vincent

...

In addition xwiki-contrib is very open and anyone can make modifications

...

there and quality is thus harder to guarantee.

We defined the xwiki github organization as containing horizontal modules, ie modules that can be required for any flavor and both CKEditor and the Tour Application fit the need. By opposition to vertical modules which make sense only for some use cases (like the Meeting Manager app) and not by default in XE. We have the option of having flavors in contrib for those if we want though. For CKEditor it’s not a good thing since we’d like it by default.

One alternative (which I’m not fond of at all) would be to have ckeditor as a separate git repo in the xwiki github organization.

Thanks -Vincent

...

Thanks, Marius

> > Thanks, > Alex

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

FTR I’ve discussed internally with Thomas, Marius and Anca and we all agreed that it makes sense to move The Tour app + CKEditor to the platform. There are various reasons but a very important one is simply the manpower that it requires to maintain extensions on lots of XWiki versions and currently the active devs on xwiki are not enough to do that. This is the reason we dropped this strategy in the past and decided to release the whole platform together with the same version. As part of this the technical debt is being increased since supporting several versions and old versions means doing hacks. If you see another possibility that doesn’t require more work please raise it here. We need to progress and have CKEditor and Tour bundled in 8.2M2(which is already started) and thus, barring any negative comments, we’ll start the move next week. Thanks -Vincent

On 07 Jun 2016, at 15:39, Guillaume Delhumeau <[email protected]> wrote:

It also means to move the tour application in that old branches too.

2016-06-07 13:59 GMT+02:00 Vincent Massol <[email protected]>:

...

...

On 07 Jun 2016, at 10:27, Vincent Massol <[email protected]> wrote:

...

On 07 Jun 2016, at 09:37, Guillaume Delhumeau < [email protected]> wrote:

Moving Tour Application into platform makes sense to me (it becomes a critical component and deserves a proper support).

For me, it’s really about the definition of what the XWiki github org represents. Right now with the new strategy == “Everything needed for the default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling XE so far but that we’ll slim down a bit, for example by removing the Blog app and move it to contrib).

Now we could still decide to have some flavor in contrib and have the tour app included in that flavor but not in “the default XWiki runtime”. In practice this would mean promoting this flavor instead of the base/default flavor. The question will arise anyway when we next talk about other flavors that we may want to have in contrib such a KB flavor, workgroup flavor, web flavor, etc.

...

However, the current application supports XWiki >= 6.4.1. By moving it to platform, we will only support the last XWiki version.

This is a tough topic indeed.

Actually in practice we would support not only the last XWiki version but also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we could (we still have a stable-6.4.x branch ATM that we were supposed to remove) but it would mean changing our support strategy to support more branches… and it means supporting the whole platform for 6.4.x, not just one extension…

Thanks -Vincent

...

For the tour there’s the solution of keeping it in contrib and introducing a flavor but for CKEditor it’s harder to justify that it’s not part of the base flavor IMO but maybe it’s possible and we would offer only the wiki editor in the base flavor. Of course we could modify our functional tests fwk to support running on various versions of the dependencies and have CI builds to ensure that an extension works with all versions but it’s not perfect and it would mean that for the first time we would have code in the xwiki github org that would not use the latest APIs/latest JDK features.

The other option is Marius’s, i.e. accept that we hand-pick some extensions from contrib that we bundle in the base/default flavor such as the Tour app, CKEditor integration, etc. In this case, we would just need to redefine what “xwiki github org” means. Saying “core component” would not be enough, it would needs a more precise definition.

Interesting topic ;)

Any other option that we have?

Thanks -Vincent

...

2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>:

...

...

On 06 Jun 2016, at 15:24, Marius Dumitru Florea < [email protected]> wrote:

On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol <[email protected]> wrote:

> >> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < > [email protected]> wrote: >> >> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >> [email protected]> wrote: >> >>> Hello all, >>> >>> As it was decided already, a Homepage Tour have to be implemented. > However, >>> no option regarding the place where the Tour Application should be > added as >>> dependency was discussed. >>> >>> There are some possible options: >>> 1) XWiki Enterprise >>> 2) XWiki Platform Distribution >>> 3) XWiki Platform Helper >>> >>> 4) Is there any option to have the Tour Application as a part of

the

...

...

> Core ? >>> >>> What would be the best way to include the Contrib applications in XWiki? >>> >> >> On this topic (sorry if I hijack your thread) I was wondering why don't > we >> have dependencies from platform/enterprise to contrib. We have lots of >> third party dependencies, contrib could be considered as such. Moreover, >> we're in the process of moving non-core (vertical) extensions out of >> platform to contrib. It would be a pity to move something from contrib to >> platform and then back to contrib. I have the same issue with the > CKEditor >> Integration extension. We want CKEditor as the default editor, bundled > with >> the default distribution, but do we need to move it to platform? Same for >> the Welcome Tour. > > I’d personally not like this for the following reasons: > >

> 1) I like that the XWiki runtime is all released at once with all > extensions making it using the same versions and verified to work together. >

XWiki runtime has lots of third party dependencies. Bootstrap, Solr, jQuery, just to name a few. I don't see how having the source code in our repo (platform) makes a difference at runtime when the integration/functional tests verify they work together.

Because they don’t! :) Just check any extension in contrib and you’ll see their func test (when they have some!) don’t test that they work with the latest version of XWiki…

...

2) Support. The XWiki runtime is supported by the XWiki Core Dev Team. > Extensions in contrib are not supported by the XWiki Core Dev Team.

So the FAQ application you moved out of platform is no longer supported by the XWiki Core Dev Team?

Correct.

...

The extension page http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application doesn't reflect this.

I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” because it's a past authors and it wouldn’t make sense to remove it. But yes it’s no longer officially supported by the XWiki Core Dev Team.

Note that e.x.o doesn’t say who maintains a given extension, it just says who participated to developing it ;) We’re currently missing the info on whether the extension is actively supported and by whom. FTR Confluence does this with a “supported” label that you can hover over and provides info. For example:

https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

...

Thanks -Vincent

...

In addition xwiki-contrib is very open and anyone can make

modifications

...

...

> there and quality is thus harder to guarantee. > > We defined the xwiki github organization as containing horizontal modules, > ie modules that can be required for any flavor and both CKEditor and the > Tour Application fit the need. By opposition to vertical modules which make > sense only for some use cases (like the Meeting Manager app) and not by > default in XE. We have the option of having flavors in contrib for those if > we want though. For CKEditor it’s not a good thing since we’d like it by > default. > > One alternative (which I’m not fond of at all) would be to have ckeditor > as a separate git repo in the xwiki github organization. > > Thanks > -Vincent > >> Thanks, >> Marius >> >> >>> >>> Thanks, >>> Alex

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, I`ve also dropped in late on this topic.

From what I understood from the XWiki Core thread, we were going to move non-vital modules to contrib, even if the default flavor (i.e. enterprise) might still be depending on them. I also understood that we have already acknowledged that this would bring back the dependency hell from the past and that we were OK with it. Now I see we`ve changed our mind again.

Even if I agree with the idea of slimming down the xwiki org repositories (yes, Tour is not vital and neither is CK) and with the advantages of having modules outside the xwiki org (individual versions, older minimum version requirements, etc.), I also can not ignore the problems that this introduces in our development process. Right now, all modules depend on each-other and any bad change in the platform can cause a module to fail. Moving to a slim xwiki core would make us lose this precious feedback tool that allows us to detect problems at development/build time and would force us to rely on manual testing (i.e. runtime) or on the automated tests of individual modules that will only be executed when a new commit is done on a possibly impacted module (from contrib). IMO, this is what the discussion is all about: the trade-off between the flexibility and independence of a module vs the stability of the module that can now be easily broken by platform changes (since we will have no way of finding out). If we can find a way (some kind of setup) to ensure that our CI builds will also trigger the builds + tests of all the modules on which enterprise (default flavor) depends on (i.e. contrib modules that have CI jobs) and when doing so the functional tests run with the latest snapshot of the platform (maybe through some build parameter), then the biggest problem would be fixed and we could go with the slim core approach. The other issue pointed out by Vincent about backwards compatible code would only apply to these contrib/independent modules and would not affect the modules that are still in XWiki core. Said differently, it will be the choice of the independent module to take the effort to remain backwards compatible and it will be done on a best-effort basis (e.g. the minimal version will not be increased without reason on every release like we do now, but when new API is introduced in platform it might be reason enough to do so); xwiki core code will continue to be developed with bleeding-edge API. IMO the current approach we have is not very realistic for a platform-based product nor is it fair to our users. We like it because it`s nicer to develop and fits well to our development capabilities (resources and people), but asking users/admins to simply upgrade to the latest version to get the improvements on app X is close to being mean, knowing very well that upgrades in XWiki are no walk in the park. Another reason why it`s mean/confusing is that we have 2 types of apps (core + contrib) and the contrib apps allow you to upgrade them individually, while core apps do not... and this does not really make sense for a user (talking about non-vital stuff here, of course). Thanks, Eduard On Wed, Jun 8, 2016 at 6:57 PM, Denis Gervalle <[email protected]> wrote:

Well, very sorry to drop in so late in this discussion, but it was not obvious from the thread subject that your were discussing a major subject.

IMO, moving application that works currently on 6.x to the core, has no benefit for our users, it just introduce restrictions. It does not have any benefit for us either, it just require more backports. I do not understand this move at all for application that are not minimal requirements. I do not understand your point Vincent when you say that these applications are horizontal and obviously part of platform according to your "Executive summary".

Regarding the tour application, it is not require at all, it is just a nice helping tool that we want to ease newcomers, but experienced user will never need it. It could be exchanged for an alternative, and it is exactly the same kind of application than the blog that we are moving out. Regarding the CKEditor, do we consider that a WYSIWYG editor is required for a wiki to be a wiki ? IMO, WYSIWYG editor is not a requirement to use the platform, it is nice to have, but not required. I have use it very sparsely until now, and not having it would not have change much for me.

So, I currently do not see any benefit of moving these modules to platform, since these are already well living in contrib.

Your other point about reducing platform to the minimal runtime would cause platform to reduce to EM does not really looks like something that will happen. In theory, you are right, so XWiki would be even less featured then maven. But, I doubt you could reasonably use such a tools for anything useful. I doubt XWiki compare to maven. I doubt that horizontal module like security, logging, model, storage, etc… will ever be considered optional. Even a plain text editor is a minimal requirement to starts, else this is no more a wiki, and I even wonder what it is ? a tool that brings together arbitrary java module… looks weird. So no, the minimal runtime is definitely not just EM.

So, I really wonder what is the direction we are taking. I will not stop you with a veto, but I have the strong feeling these decisions are wrong. For the principle of not depending on contrib for our default user flavor, exchanging the blog app with the tour app, this does not make sens for me, sorry.

Thanks for reading.

On Wed, Jun 8, 2016 at 3:45 PM, Vincent Massol <[email protected]> wrote:

...

FTR I’ve discussed internally with Thomas, Marius and Anca and we all agreed that it makes sense to move The Tour app + CKEditor to the platform.

There are various reasons but a very important one is simply the manpower that it requires to maintain extensions on lots of XWiki versions and currently the active devs on xwiki are not enough to do that. This is the reason we dropped this strategy in the past and decided to release the whole platform together with the same version.

As part of this the technical debt is being increased since supporting several versions and old versions means doing hacks.

If you see another possibility that doesn’t require more work please raise it here.

We need to progress and have CKEditor and Tour bundled in 8.2M2(which is already started) and thus, barring any negative comments, we’ll start the move next week.

Thanks -Vincent

...

On 07 Jun 2016, at 15:39, Guillaume Delhumeau < [email protected]> wrote:

It also means to move the tour application in that old branches too.

2016-06-07 13:59 GMT+02:00 Vincent Massol <[email protected]>:

...

...

On 07 Jun 2016, at 10:27, Vincent Massol <[email protected]> wrote:

...

On 07 Jun 2016, at 09:37, Guillaume Delhumeau < [email protected]> wrote:

Moving Tour Application into platform makes sense to me (it becomes

a

...

...

...

critical component and deserves a proper support).

For me, it’s really about the definition of what the XWiki github org represents. Right now with the new strategy == “Everything needed for the default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling XE so far but that we’ll slim down a bit, for example by removing the Blog app and move it to contrib).

Now we could still decide to have some flavor in contrib and have the tour app included in that flavor but not in “the default XWiki runtime”. In practice this would mean promoting this flavor instead of the base/default flavor. The question will arise anyway when we next talk about other flavors that we may want to have in contrib such a KB flavor, workgroup flavor, web flavor, etc.

...

However, the current application supports XWiki >= 6.4.1. By moving it to platform, we will only support the last XWiki version.

This is a tough topic indeed.

Actually in practice we would support not only the last XWiki version but also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we could (we still have a stable-6.4.x branch ATM that we were supposed to remove) but it would mean changing our support strategy to support more branches… and it means supporting the whole platform for 6.4.x, not just one extension…

Thanks -Vincent

...

For the tour there’s the solution of keeping it in contrib and introducing a flavor but for CKEditor it’s harder to justify that it’s not part of the base flavor IMO but maybe it’s possible and we would offer only the wiki editor in the base flavor. Of course we could modify our functional tests fwk to support running on various versions of the dependencies and have CI builds to ensure that an extension works with all versions but it’s not perfect and it would mean that for the first time we would have code in the xwiki github org that would not use the latest APIs/latest JDK features.

The other option is Marius’s, i.e. accept that we hand-pick some extensions from contrib that we bundle in the base/default flavor such as the Tour app, CKEditor integration, etc. In this case, we would just need to redefine what “xwiki github org” means. Saying “core component” would not be enough, it would needs a more precise definition.

Interesting topic ;)

Any other option that we have?

Thanks -Vincent

...

2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>:

> >> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < > [email protected]> wrote: >> >> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol < [email protected]> > wrote: >> >>> >>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < >>> [email protected]> wrote: >>>> >>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >>>> [email protected]> wrote: >>>> >>>>> Hello all, >>>>> >>>>> As it was decided already, a Homepage Tour have to be implemented. >>> However, >>>>> no option regarding the place where the Tour Application should be >>> added as >>>>> dependency was discussed. >>>>> >>>>> There are some possible options: >>>>> 1) XWiki Enterprise >>>>> 2) XWiki Platform Distribution >>>>> 3) XWiki Platform Helper >>>>> >>>>> 4) Is there any option to have the Tour Application as a part of the >>> Core ? >>>>> >>>>> What would be the best way to include the Contrib applications in > XWiki? >>>>> >>>> >>>> On this topic (sorry if I hijack your thread) I was wondering why don't >>> we >>>> have dependencies from platform/enterprise to contrib. We have lots of >>>> third party dependencies, contrib could be considered as such. > Moreover, >>>> we're in the process of moving non-core (vertical) extensions out of >>>> platform to contrib. It would be a pity to move something from contrib > to >>>> platform and then back to contrib. I have the same issue with the >>> CKEditor >>>> Integration extension. We want CKEditor as the default editor, bundled >>> with >>>> the default distribution, but do we need to move it to platform? Same > for >>>> the Welcome Tour. >>> >>> I’d personally not like this for the following reasons: >>> >>> >> >>> 1) I like that the XWiki runtime is all released at once with all >>> extensions making it using the same versions and verified to work > together. >>> >> >> XWiki runtime has lots of third party dependencies. Bootstrap, Solr, >> jQuery, just to name a few. I don't see how having the source code in our >> repo (platform) makes a difference at runtime when the >> integration/functional tests verify they work together. > > Because they don’t! :) Just check any extension in contrib and you’ll see > their func test (when they have some!) don’t test that they work with the > latest version of XWiki… > >> 2) Support. The XWiki runtime is supported by the XWiki Core Dev Team. >>> Extensions in contrib are not supported by the XWiki Core Dev Team. >> >> >> So the FAQ application you moved out of platform is no longer supported > by >> the XWiki Core Dev Team? > > Correct. > >> The extension page >> http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application >> doesn't reflect this. > > I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” > because it's a past authors and it wouldn’t make sense to remove it. But > yes it’s no longer officially supported by the XWiki Core Dev Team. > > Note that e.x.o doesn’t say who maintains a given extension, it just says > who participated to developing it ;) We’re currently missing the info on > whether the extension is actively supported and by whom. FTR Confluence > does this with a “supported” label that you can hover over and provides > info. For example: >

https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

...

...

...

...

...

> > Thanks > -Vincent > >> In addition xwiki-contrib is very open and anyone can make modifications >>> there and quality is thus harder to guarantee. >>> >>> We defined the xwiki github organization as containing horizontal > modules, >>> ie modules that can be required for any flavor and both CKEditor and the >>> Tour Application fit the need. By opposition to vertical modules which > make >>> sense only for some use cases (like the Meeting Manager app) and not by >>> default in XE. We have the option of having flavors in contrib for > those if >>> we want though. For CKEditor it’s not a good thing since we’d like it by >>> default. >>> >>> One alternative (which I’m not fond of at all) would be to have ckeditor >>> as a separate git repo in the xwiki github organization. >>> >>> Thanks >>> -Vincent >>> >>>> Thanks, >>>> Marius >>>> >>>> >>>>> >>>>> Thanks, >>>>> Alex > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, Where are the Flavors in this proposal? Thanks, Caty On Thu, Jun 9, 2016 at 12:01 PM, Vincent Massol <[email protected]> wrote:

Hi everyone,

Thanks for the replies. I’m listening of course to everyone and I’ve tried in this mail to take all answers into account.

First, let me state our current strategy and an alternative that I’ve been thinking about this morning under my shower ;)

Current Voted Strategy ==================

* Deliver an XWiki Runtime that is the best possible generic runtime (i.e. most usable, most useful). * As a consequence, remove all modules that vertical modules (i.e. that are clearly not useful to all flavors), such as FAQ, Blog, etc. Move them to xwiki-contrib * I want to stress out that the current voted strategy is not to produce a minimalist runtime

New Strategy Proposal ==================

I’ve tried to reconcile all the use cases listed in this thread before and I hope this proposal could be a good middle ground. In any case I found it worth debating to see if it could work.

Also note that one aspect that we must not forget (and that led to the last proposal I sent on this thread) and that people tend to forget, is the time it takes to support various versions of XE in an extension and the manpower that exists in the xwiki community (don’t forget that everything we do is a tradeoff; if you support another version of XE in an extension, it means you’re not coding an important improvement or fixing an important bug in the platform).

So here’s the idea:

* Change the purpose of the XWiki Github organization from the voted one described above to be: Provide a minimalist runtime. * Since working in this direction will not happen overnight, the idea would be to very slowly take out modules, starting with obvious ones. * The issue that this strategy raises is that users will not get a good user experience since lots of things will be lacking and this is where my new idea fills the gap: ** The first time (or whenever you upgrade) your run the XWiki Runtime (be it whether your run the HSQLDB/Jetty packaging or any other packaging) you get a Configuration wizard ** This Configuration Wizard suggest some recommended extensions that the XWiki Core Dev Team hand-pick. We would start with 2: *** Propose to the user to run a Tour to learn how to use XWiki (it would install the Home Page Tour which depends on the Tour app) *** Propose to the user to install the CKEDitor WYSIWYG editor (by default we would only propose the wiki editor - We’ll need to get rid of the GWT editor, probably make it an extension)

Pros: * The XWiki Core Dev Team continues to work on core stuff and as time progresses we move out non core stuff * This allows more people to contribute to the non-core stuff in the community * We control which extensions we want to recommend and thus we can always only take the very good ones and thus control the quality of the initial user experience * We get a mechanism allowing our users to get non-xwiki core dev team-supported extensions into the runtime (thus providing a good user experience) while not bundling them into the default XWiki runtime flavor.

Cons: * The Tour and CKeditor extensions would still incur a higher cost of support/maintenance (but since they’ve already done the code, it’s marginal for the future and they’ll be able to abandon support for XWiki 6.x soon IMO too - Basically they probably only need to support 2 or 2.5 cycle versions).

<similar idea> Ludo mentioned (and I agree with him) that it would be nice to be able to provide Demo content in the wiki so that users who want to test drive XWiki can do so with existing content and more clearly see and understand the advantages that XWiki brings. For this, I’d propose to create a Demo Content extension (some AWM app + some blog posts + etc) and once we have it, recommend it on the Configuration Wizard. </similar idea>

WDYT?

Thanks -Vincent

...

On 08 Jun 2016, at 17:57, Denis Gervalle <[email protected]> wrote:

Well, very sorry to drop in so late in this discussion, but it was not obvious from the thread subject that your were discussing a major subject.

IMO, moving application that works currently on 6.x to the core, has no benefit for our users, it just introduce restrictions. It does not have any benefit for us either, it just require more backports. I do not understand this move at all for application that are not minimal requirements. I do not understand your point Vincent when you say that these applications are horizontal and obviously part of platform according to your "Executive summary".

Regarding the tour application, it is not require at all, it is just a nice helping tool that we want to ease newcomers, but experienced user will never need it. It could be exchanged for an alternative, and it is exactly the same kind of application than the blog that we are moving out. Regarding the CKEditor, do we consider that a WYSIWYG editor is required for a wiki to be a wiki ? IMO, WYSIWYG editor is not a requirement to use the platform, it is nice to have, but not required. I have use it very sparsely until now, and not having it would not have change much for me.

So, I currently do not see any benefit of moving these modules to platform, since these are already well living in contrib.

Your other point about reducing platform to the minimal runtime would cause platform to reduce to EM does not really looks like something that will happen. In theory, you are right, so XWiki would be even less featured then maven. But, I doubt you could reasonably use such a tools for anything useful. I doubt XWiki compare to maven. I doubt that horizontal module like security, logging, model, storage, etc… will ever be considered optional. Even a plain text editor is a minimal requirement to starts, else this is no more a wiki, and I even wonder what it is ? a tool that brings together arbitrary java module… looks weird. So no, the minimal runtime is definitely not just EM.

So, I really wonder what is the direction we are taking. I will not stop you with a veto, but I have the strong feeling these decisions are wrong. For the principle of not depending on contrib for our default user flavor, exchanging the blog app with the tour app, this does not make sens for me, sorry.

Thanks for reading.

On Wed, Jun 8, 2016 at 3:45 PM, Vincent Massol <[email protected]> wrote:

...

FTR I’ve discussed internally with Thomas, Marius and Anca and we all agreed that it makes sense to move The Tour app + CKEditor to the platform.

There are various reasons but a very important one is simply the manpower that it requires to maintain extensions on lots of XWiki versions and currently the active devs on xwiki are not enough to do that. This is the reason we dropped this strategy in the past and decided to release the whole platform together with the same version.

As part of this the technical debt is being increased since supporting several versions and old versions means doing hacks.

If you see another possibility that doesn’t require more work please raise it here.

We need to progress and have CKEditor and Tour bundled in 8.2M2(which is already started) and thus, barring any negative comments, we’ll start the move next week.

Thanks -Vincent

...

On 07 Jun 2016, at 15:39, Guillaume Delhumeau < [email protected]> wrote:

It also means to move the tour application in that old branches too.

2016-06-07 13:59 GMT+02:00 Vincent Massol <[email protected]>:

...

...

On 07 Jun 2016, at 10:27, Vincent Massol <[email protected]> wrote:

> On 07 Jun 2016, at 09:37, Guillaume Delhumeau < [email protected]> wrote: > > Moving Tour Application into platform makes sense to me (it becomes

a

...

...

> critical component and deserves a proper support).

For me, it’s really about the definition of what the XWiki github org represents. Right now with the new strategy == “Everything needed for the default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling XE so far but that we’ll slim down a bit, for example by removing the Blog app and move it to contrib).

Now we could still decide to have some flavor in contrib and have the tour app included in that flavor but not in “the default XWiki runtime”. In practice this would mean promoting this flavor instead of the base/default flavor. The question will arise anyway when we next talk about other flavors that we may want to have in contrib such a KB flavor, workgroup flavor, web flavor, etc.

> However, the current > application supports XWiki >= 6.4.1. By moving it to platform, we will only > support the last XWiki version.

This is a tough topic indeed.

Actually in practice we would support not only the last XWiki version but also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we could (we still have a stable-6.4.x branch ATM that we were supposed to remove) but it would mean changing our support strategy to support more branches… and it means supporting the whole platform for 6.4.x, not just one extension…

Thanks -Vincent

...

For the tour there’s the solution of keeping it in contrib and introducing a flavor but for CKEditor it’s harder to justify that it’s not part of the base flavor IMO but maybe it’s possible and we would offer only the wiki editor in the base flavor. Of course we could modify our functional tests fwk to support running on various versions of the dependencies and have CI builds to ensure that an extension works with all versions but it’s not perfect and it would mean that for the first time we would have code in the xwiki github org that would not use the latest APIs/latest JDK features.

The other option is Marius’s, i.e. accept that we hand-pick some extensions from contrib that we bundle in the base/default flavor such as the Tour app, CKEditor integration, etc. In this case, we would just need to redefine what “xwiki github org” means. Saying “core component” would not be enough, it would needs a more precise definition.

Interesting topic ;)

Any other option that we have?

Thanks -Vincent

> 2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>: > >> >>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < >> [email protected]> wrote: >>> >>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol < [email protected]> >> wrote: >>> >>>> >>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < >>>> [email protected]> wrote: >>>>> >>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >>>>> [email protected]> wrote: >>>>> >>>>>> Hello all, >>>>>> >>>>>> As it was decided already, a Homepage Tour have to be implemented. >>>> However, >>>>>> no option regarding the place where the Tour Application should be >>>> added as >>>>>> dependency was discussed. >>>>>> >>>>>> There are some possible options: >>>>>> 1) XWiki Enterprise >>>>>> 2) XWiki Platform Distribution >>>>>> 3) XWiki Platform Helper >>>>>> >>>>>> 4) Is there any option to have the Tour Application as a part of the >>>> Core ? >>>>>> >>>>>> What would be the best way to include the Contrib applications in >> XWiki? >>>>>> >>>>> >>>>> On this topic (sorry if I hijack your thread) I was wondering why don't >>>> we >>>>> have dependencies from platform/enterprise to contrib. We have lots of >>>>> third party dependencies, contrib could be considered as such. >> Moreover, >>>>> we're in the process of moving non-core (vertical) extensions out of >>>>> platform to contrib. It would be a pity to move something from contrib >> to >>>>> platform and then back to contrib. I have the same issue with the >>>> CKEditor >>>>> Integration extension. We want CKEditor as the default editor, bundled >>>> with >>>>> the default distribution, but do we need to move it to platform? Same >> for >>>>> the Welcome Tour. >>>> >>>> I’d personally not like this for the following reasons: >>>> >>>> >>> >>>> 1) I like that the XWiki runtime is all released at once with all >>>> extensions making it using the same versions and verified to work >> together. >>>> >>> >>> XWiki runtime has lots of third party dependencies. Bootstrap, Solr, >>> jQuery, just to name a few. I don't see how having the source code in our >>> repo (platform) makes a difference at runtime when the >>> integration/functional tests verify they work together. >> >> Because they don’t! :) Just check any extension in contrib and you’ll see >> their func test (when they have some!) don’t test that they work with the >> latest version of XWiki… >> >>> 2) Support. The XWiki runtime is supported by the XWiki Core Dev Team. >>>> Extensions in contrib are not supported by the XWiki Core Dev Team. >>> >>> >>> So the FAQ application you moved out of platform is no longer supported >> by >>> the XWiki Core Dev Team? >> >> Correct. >> >>> The extension page >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application >>> doesn't reflect this. >> >> I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” >> because it's a past authors and it wouldn’t make sense to remove it. But >> yes it’s no longer officially supported by the XWiki Core Dev Team. >> >> Note that e.x.o doesn’t say who maintains a given extension, it just says >> who participated to developing it ;) We’re currently missing the info on >> whether the extension is actively supported and by whom. FTR Confluence >> does this with a “supported” label that you can hover over and provides >> info. For example: >>

https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

...

...

...

...

>> >> Thanks >> -Vincent >> >>> In addition xwiki-contrib is very open and anyone can make modifications >>>> there and quality is thus harder to guarantee. >>>> >>>> We defined the xwiki github organization as containing horizontal >> modules, >>>> ie modules that can be required for any flavor and both CKEditor and the >>>> Tour Application fit the need. By opposition to vertical modules which >> make >>>> sense only for some use cases (like the Meeting Manager app) and not by >>>> default in XE. We have the option of having flavors in contrib for >> those if >>>> we want though. For CKEditor it’s not a good thing since we’d like it by >>>> default. >>>> >>>> One alternative (which I’m not fond of at all) would be to have ckeditor >>>> as a separate git repo in the xwiki github organization. >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> Thanks, >>>>> Marius >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Alex

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

I think that if we are to have Recommended extensions inside e.x.o and EM, I would consider it a bit too much to have them also in DW. But maybe this is another discussion. Thanks, Caty On Thu, Jun 9, 2016 at 1:50 PM, Vincent Massol <[email protected]> wrote:

...

On 09 Jun 2016, at 11:15, Ecaterina Moraru (Valica) <[email protected]> wrote:

Hi,

Where are the Flavors in this proposal?

IMO Flavors don’t change; they’re still there and you still get them when you start with an empty wiki. When you start an empty wiki you pick the flavor you want and on the configuration screen, there are some recommended extensions that are proposed. I think that’s the difference: flavors are a fixed set of extensions. The Recommended extensions screen is just for optional stuff that you may want. If the recommended extensins are brought as part of the flavor (ie if they are already installed) then they won’t be suggested on the configuration screen.

Basically flavors are distribution. Once you install a distribution you can still install additional extensions by going to the Extension Manager. However we make the user’s file easier when he starts the first time by proposing some extensions.

This provides 2 advantages: * We bring extensions that we deem important but that are not maintainted by the xwiki core dev team to the user. He doesn’t need to discover the EM UI nor find out which extensions are super nice for me. * It allows to propose some extensions that need to run early in the process, such as the Tour (the user needs the Tour to know how to reach the EM UI ;)).

Another way of viewing this is that it’s a new feature of the EM/DW UI. The EM/DW module would provide a Recommended Extensions view as a Wizard when XWiki runtime starts the first time (and at each upgrade). Now what we would need to be careful about is not drowning the user under 50 recommended extensions or it would loose its power. I think this config wizard view should focus on Extensions that are super useful for getting started. Then later one the user could go to the EM UI and get a full list of Recommended Extensions, not just the one important for getting started.

WDYT?

Thanks -Vincent

...

Thanks, Caty

On Thu, Jun 9, 2016 at 12:01 PM, Vincent Massol <[email protected]> wrote:

...

Hi everyone,

Thanks for the replies. I’m listening of course to everyone and I’ve tried in this mail to take all answers into account.

First, let me state our current strategy and an alternative that I’ve been thinking about this morning under my shower ;)

Current Voted Strategy ==================

* Deliver an XWiki Runtime that is the best possible generic runtime (i.e. most usable, most useful). * As a consequence, remove all modules that vertical modules (i.e. that are clearly not useful to all flavors), such as FAQ, Blog, etc. Move them to xwiki-contrib * I want to stress out that the current voted strategy is not to produce a minimalist runtime

New Strategy Proposal ==================

I’ve tried to reconcile all the use cases listed in this thread before and I hope this proposal could be a good middle ground. In any case I found it worth debating to see if it could work.

Also note that one aspect that we must not forget (and that led to the last proposal I sent on this thread) and that people tend to forget, is the time it takes to support various versions of XE in an extension and the manpower that exists in the xwiki community (don’t forget that everything we do is a tradeoff; if you support another version of XE in an extension, it means you’re not coding an important improvement or fixing an important bug in the platform).

So here’s the idea:

* Change the purpose of the XWiki Github organization from the voted one described above to be: Provide a minimalist runtime. * Since working in this direction will not happen overnight, the idea would be to very slowly take out modules, starting with obvious ones. * The issue that this strategy raises is that users will not get a good user experience since lots of things will be lacking and this is where my new idea fills the gap: ** The first time (or whenever you upgrade) your run the XWiki Runtime (be it whether your run the HSQLDB/Jetty packaging or any other packaging) you get a Configuration wizard ** This Configuration Wizard suggest some recommended extensions that the XWiki Core Dev Team hand-pick. We would start with 2: *** Propose to the user to run a Tour to learn how to use XWiki (it would install the Home Page Tour which depends on the Tour app) *** Propose to the user to install the CKEDitor WYSIWYG editor (by default we would only propose the wiki editor - We’ll need to get rid of the GWT editor, probably make it an extension)

Pros: * The XWiki Core Dev Team continues to work on core stuff and as time progresses we move out non core stuff * This allows more people to contribute to the non-core stuff in the community * We control which extensions we want to recommend and thus we can always only take the very good ones and thus control the quality of the initial user experience * We get a mechanism allowing our users to get non-xwiki core dev team-supported extensions into the runtime (thus providing a good user experience) while not bundling them into the default XWiki runtime flavor.

Cons: * The Tour and CKeditor extensions would still incur a higher cost of support/maintenance (but since they’ve already done the code, it’s marginal for the future and they’ll be able to abandon support for XWiki 6.x soon IMO too - Basically they probably only need to support 2 or 2.5 cycle versions).

<similar idea> Ludo mentioned (and I agree with him) that it would be nice to be able to provide Demo content in the wiki so that users who want to test drive XWiki can do so with existing content and more clearly see and understand the advantages that XWiki brings. For this, I’d propose to create a Demo Content extension (some AWM app + some blog posts + etc) and once we have it, recommend it on the Configuration Wizard. </similar idea>

WDYT?

Thanks -Vincent

...

On 08 Jun 2016, at 17:57, Denis Gervalle <[email protected]> wrote:

Well, very sorry to drop in so late in this discussion, but it was not obvious from the thread subject that your were discussing a major subject.

IMO, moving application that works currently on 6.x to the core, has no benefit for our users, it just introduce restrictions. It does not have any benefit for us either, it just require more backports. I do not understand this move at all for application that are not minimal requirements. I do not understand your point Vincent when you say that these applications are horizontal and obviously part of platform according to your "Executive summary".

Regarding the tour application, it is not require at all, it is just a nice helping tool that we want to ease newcomers, but experienced user will never need it. It could be exchanged for an alternative, and it is exactly the same kind of application than the blog that we are moving out. Regarding the CKEditor, do we consider that a WYSIWYG editor is required for a wiki to be a wiki ? IMO, WYSIWYG editor is not a requirement to use the platform, it is nice to have, but not required. I have use it very sparsely until now, and not having it would not have change much for me.

So, I currently do not see any benefit of moving these modules to platform, since these are already well living in contrib.

Your other point about reducing platform to the minimal runtime would cause platform to reduce to EM does not really looks like something that will happen. In theory, you are right, so XWiki would be even less featured then maven. But, I doubt you could reasonably use such a tools for anything useful. I doubt XWiki compare to maven. I doubt that horizontal module like security, logging, model, storage, etc… will ever be considered optional. Even a plain text editor is a minimal requirement to starts, else this is no more a wiki, and I even wonder what it is ? a tool that brings together arbitrary java module… looks weird. So no, the minimal runtime is definitely not just EM.

So, I really wonder what is the direction we are taking. I will not stop you with a veto, but I have the strong feeling these decisions are wrong. For the principle of not depending on contrib for our default user flavor, exchanging the blog app with the tour app, this does not make sens for me, sorry.

Thanks for reading.

On Wed, Jun 8, 2016 at 3:45 PM, Vincent Massol <[email protected]> wrote:

...

FTR I’ve discussed internally with Thomas, Marius and Anca and we all agreed that it makes sense to move The Tour app + CKEditor to the platform.

There are various reasons but a very important one is simply the manpower that it requires to maintain extensions on lots of XWiki versions and currently the active devs on xwiki are not enough to do that. This is the reason we dropped this strategy in the past and decided to release the whole platform together with the same version.

As part of this the technical debt is being increased since supporting several versions and old versions means doing hacks.

If you see another possibility that doesn’t require more work please raise it here.

We need to progress and have CKEditor and Tour bundled in 8.2M2(which is already started) and thus, barring any negative comments, we’ll start the move next week.

Thanks -Vincent

...

On 07 Jun 2016, at 15:39, Guillaume Delhumeau < [email protected]> wrote:

It also means to move the tour application in that old branches too.

2016-06-07 13:59 GMT+02:00 Vincent Massol <[email protected]>:

> >> On 07 Jun 2016, at 10:27, Vincent Massol <[email protected]> wrote: >> >> >>> On 07 Jun 2016, at 09:37, Guillaume Delhumeau < > [email protected]> wrote: >>> >>> Moving Tour Application into platform makes sense to me (it becomes a >>> critical component and deserves a proper support). >> >> For me, it’s really about the definition of what the XWiki github org > represents. Right now with the new strategy == “Everything needed for the > default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling > XE so far but that we’ll slim down a bit, for example by removing the Blog > app and move it to contrib). >> >> Now we could still decide to have some flavor in contrib and have the > tour app included in that flavor but not in “the default XWiki runtime”. In > practice this would mean promoting this flavor instead of the base/default > flavor. The question will arise anyway when we next talk about other > flavors that we may want to have in contrib such a KB flavor, workgroup > flavor, web flavor, etc. >> >>> However, the current >>> application supports XWiki >= 6.4.1. By moving it to platform, we will > only >>> support the last XWiki version. >> >> This is a tough topic indeed. > > Actually in practice we would support not only the last XWiki version but > also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we could (we > still have a stable-6.4.x branch ATM that we were supposed to remove) but > it would mean changing our support strategy to support more branches… and > it means supporting the whole platform for 6.4.x, not just one extension… > > Thanks > -Vincent > > >> For the tour there’s the solution of keeping it in contrib and > introducing a flavor but for CKEditor it’s harder to justify that it’s not > part of the base flavor IMO but maybe it’s possible and we would offer only > the wiki editor in the base flavor. Of course we could modify our > functional tests fwk to support running on various versions of the > dependencies and have CI builds to ensure that an extension works with all > versions but it’s not perfect and it would mean that for the first time we > would have code in the xwiki github org that would not use the latest > APIs/latest JDK features. >> >> The other option is Marius’s, i.e. accept that we hand-pick some > extensions from contrib that we bundle in the base/default flavor such as > the Tour app, CKEditor integration, etc. In this case, we would just need > to redefine what “xwiki github org” means. Saying “core component” would > not be enough, it would needs a more precise definition. >> >> Interesting topic ;) >> >> Any other option that we have? >> >> Thanks >> -Vincent >> >>> 2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>: >>> >>>> >>>>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < >>>> [email protected]> wrote: >>>>> >>>>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol < [email protected]> >>>> wrote: >>>>> >>>>>> >>>>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < >>>>>> [email protected]> wrote: >>>>>>> >>>>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hello all, >>>>>>>> >>>>>>>> As it was decided already, a Homepage Tour have to be implemented. >>>>>> However, >>>>>>>> no option regarding the place where the Tour Application should be >>>>>> added as >>>>>>>> dependency was discussed. >>>>>>>> >>>>>>>> There are some possible options: >>>>>>>> 1) XWiki Enterprise >>>>>>>> 2) XWiki Platform Distribution >>>>>>>> 3) XWiki Platform Helper >>>>>>>> >>>>>>>> 4) Is there any option to have the Tour Application as a part of > the >>>>>> Core ? >>>>>>>> >>>>>>>> What would be the best way to include the Contrib applications in >>>> XWiki? >>>>>>>> >>>>>>> >>>>>>> On this topic (sorry if I hijack your thread) I was wondering why > don't >>>>>> we >>>>>>> have dependencies from platform/enterprise to contrib. We have lots > of >>>>>>> third party dependencies, contrib could be considered as such. >>>> Moreover, >>>>>>> we're in the process of moving non-core (vertical) extensions out of >>>>>>> platform to contrib. It would be a pity to move something from > contrib >>>> to >>>>>>> platform and then back to contrib. I have the same issue with the >>>>>> CKEditor >>>>>>> Integration extension. We want CKEditor as the default editor, > bundled >>>>>> with >>>>>>> the default distribution, but do we need to move it to platform? > Same >>>> for >>>>>>> the Welcome Tour. >>>>>> >>>>>> I’d personally not like this for the following reasons: >>>>>> >>>>>> >>>>> >>>>>> 1) I like that the XWiki runtime is all released at once with all >>>>>> extensions making it using the same versions and verified to work >>>> together. >>>>>> >>>>> >>>>> XWiki runtime has lots of third party dependencies. Bootstrap, Solr, >>>>> jQuery, just to name a few. I don't see how having the source code in > our >>>>> repo (platform) makes a difference at runtime when the >>>>> integration/functional tests verify they work together. >>>> >>>> Because they don’t! :) Just check any extension in contrib and you’ll > see >>>> their func test (when they have some!) don’t test that they work with > the >>>> latest version of XWiki… >>>> >>>>> 2) Support. The XWiki runtime is supported by the XWiki Core Dev Team. >>>>>> Extensions in contrib are not supported by the XWiki Core Dev Team. >>>>> >>>>> >>>>> So the FAQ application you moved out of platform is no longer > supported >>>> by >>>>> the XWiki Core Dev Team? >>>> >>>> Correct. >>>> >>>>> The extension page >>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application >>>>> doesn't reflect this. >>>> >>>> I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” >>>> because it's a past authors and it wouldn’t make sense to remove it. > But >>>> yes it’s no longer officially supported by the XWiki Core Dev Team. >>>> >>>> Note that e.x.o doesn’t say who maintains a given extension, it just > says >>>> who participated to developing it ;) We’re currently missing the info > on >>>> whether the extension is actively supported and by whom. FTR Confluence >>>> does this with a “supported” label that you can hover over and provides >>>> info. For example: >>>> >

https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

...

...

...

...

>>>> >>>> Thanks >>>> -Vincent >>>> >>>>> In addition xwiki-contrib is very open and anyone can make > modifications >>>>>> there and quality is thus harder to guarantee. >>>>>> >>>>>> We defined the xwiki github organization as containing horizontal >>>> modules, >>>>>> ie modules that can be required for any flavor and both CKEditor and > the >>>>>> Tour Application fit the need. By opposition to vertical modules > which >>>> make >>>>>> sense only for some use cases (like the Meeting Manager app) and not > by >>>>>> default in XE. We have the option of having flavors in contrib for >>>> those if >>>>>> we want though. For CKEditor it’s not a good thing since we’d like > it by >>>>>> default. >>>>>> >>>>>> One alternative (which I’m not fond of at all) would be to have > ckeditor >>>>>> as a separate git repo in the xwiki github organization. >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> Thanks, >>>>>>> Marius >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alex

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 09 Jun 2016, at 13:45, Eduard Moraru <[email protected]> wrote:

Hi,

As far as I can see, you want to make sure that the user installs the Tour,

Yep

for example, so that it is executed at the right time. However, why not let the flavor take care of this? Since the user will be choosing a flavor to install, it would also contain the tour (if it needs it) and everything will be set up.

That wouldn’t work for 2 reasons: * You only pick a flavor when you start with an empty wiki. So this isn’t the case for Jetty/HSQLDB distribution which is the most important packaging for people trying out XWiki. * We would have 2 flavors: the default one (and we would need somehow to prevent users from installing it, basically making the flavor useless) and the other one which would be the recommended one. The goal of the idea I sent this morning is to have a single runtime flavor provided by the XWiki Core dev team that is generic but as useful as possible to users.

For additional extensions that the admin wants to install, we have the EM UI and we can have recommended extensions displayed there.

An extra step just for the recommended extensions is too much IMO and just gets in the way.

FTR This is exactly what happens when you install several softwares including Jenkins 2, IntelliJ IDEA and more.

We still control what the standard flavor contains (tour, CK, etc.) and we still control what (contrib) extensions to recommend in the EM UI. IMO, that is enough.

Ah I see what you mean. The other goal of the last proposal is to not have to bundle any extension (that’s really important IMO), ie. the XWiki Core Dev team doesn’t bundle any non xwiki github org code. Users can install contrib stuff at runtime and pick the version they want/need. In addition this makes it possible for users to use the latest version of the extensions. For example: imagine that we release XWiki 8.2 with a dependency on CKEditor v1.7. Now, in the meantime CKEditor 1.8 is released. If we were providing a flavor for it in XWiki 8.2 then users wouldn’t be able to install version 1.8 Thanks -Vincent

Thanks, Eduard

On Thu, Jun 9, 2016 at 2:12 PM, Ecaterina Moraru (Valica) <[email protected]

...

wrote:

...

I think that if we are to have Recommended extensions inside e.x.o and EM, I would consider it a bit too much to have them also in DW. But maybe this is another discussion.

Thanks, Caty

On Thu, Jun 9, 2016 at 1:50 PM, Vincent Massol <[email protected]> wrote:

...

...

On 09 Jun 2016, at 11:15, Ecaterina Moraru (Valica) <[email protected]

wrote:

...

Hi,

Where are the Flavors in this proposal?

IMO Flavors don’t change; they’re still there and you still get them when you start with an empty wiki. When you start an empty wiki you pick the flavor you want and on the configuration screen, there are some

recommended

...

extensions that are proposed. I think that’s the difference: flavors are a fixed set of extensions. The Recommended extensions screen is just for optional stuff that you may want. If the recommended extensins are brought as part of the flavor (ie if they are already installed) then they won’t be suggested on the configuration screen.

Basically flavors are distribution. Once you install a distribution you can still install additional extensions by going to the Extension Manager. However we make the user’s file easier when he starts the first time by proposing some extensions.

This provides 2 advantages: * We bring extensions that we deem important but that are not maintainted by the xwiki core dev team to the user. He doesn’t need to discover the EM UI nor find out which extensions are super nice for me. * It allows to propose some extensions that need to run early in the process, such as the Tour (the user needs the Tour to know how to reach the EM UI ;)).

Another way of viewing this is that it’s a new feature of the EM/DW UI. The EM/DW module would provide a Recommended Extensions view as a Wizard when XWiki runtime starts the first time (and at each upgrade). Now what we would need to be careful about is not drowning the user under 50 recommended extensions or it would loose its power. I think this config wizard view should focus on Extensions that are super useful for getting started. Then later one the user could go to the EM UI and get a full list of Recommended Extensions, not just the one important for getting started.

WDYT?

Thanks -Vincent

...

Thanks, Caty

On Thu, Jun 9, 2016 at 12:01 PM, Vincent Massol <[email protected]> wrote:

...

Hi everyone,

Thanks for the replies. I’m listening of course to everyone and I’ve tried in this mail to take all answers into account.

First, let me state our current strategy and an alternative that I’ve been thinking about this morning under my shower ;)

Current Voted Strategy ==================

* Deliver an XWiki Runtime that is the best possible generic runtime (i.e. most usable, most useful). * As a consequence, remove all modules that vertical modules (i.e. that are clearly not useful to all flavors), such as FAQ, Blog, etc. Move them to xwiki-contrib * I want to stress out that the current voted strategy is not to produce a minimalist runtime

New Strategy Proposal ==================

I’ve tried to reconcile all the use cases listed in this thread before and I hope this proposal could be a good middle ground. In any case I found it worth debating to see if it could work.

Also note that one aspect that we must not forget (and that led to the last proposal I sent on this thread) and that people tend to forget, is the time it takes to support various versions of XE in an extension and the manpower that exists in the xwiki community (don’t forget that everything we do is a tradeoff; if you support another version of XE in an extension, it means you’re not coding an important improvement or fixing an important bug in the platform).

So here’s the idea:

* Change the purpose of the XWiki Github organization from the voted one described above to be: Provide a minimalist runtime. * Since working in this direction will not happen overnight, the idea would be to very slowly take out modules, starting with obvious ones. * The issue that this strategy raises is that users will not get a good user experience since lots of things will be lacking and this is where my new idea fills the gap: ** The first time (or whenever you upgrade) your run the XWiki Runtime (be it whether your run the HSQLDB/Jetty packaging or any other packaging) you get a Configuration wizard ** This Configuration Wizard suggest some recommended extensions that the XWiki Core Dev Team hand-pick. We would start with 2: *** Propose to the user to run a Tour to learn how to use XWiki (it would install the Home Page Tour which depends on the Tour app) *** Propose to the user to install the CKEDitor WYSIWYG editor (by default we would only propose the wiki editor - We’ll need to get rid of the GWT editor, probably make it an extension)

Pros: * The XWiki Core Dev Team continues to work on core stuff and as time progresses we move out non core stuff * This allows more people to contribute to the non-core stuff in the community * We control which extensions we want to recommend and thus we can always only take the very good ones and thus control the quality of the initial user experience * We get a mechanism allowing our users to get non-xwiki core dev team-supported extensions into the runtime (thus providing a good user experience) while not bundling them into the default XWiki runtime flavor.

Cons: * The Tour and CKeditor extensions would still incur a higher cost of support/maintenance (but since they’ve already done the code, it’s marginal for the future and they’ll be able to abandon support for XWiki 6.x soon IMO too - Basically they probably only need to support 2 or 2.5 cycle versions).

<similar idea> Ludo mentioned (and I agree with him) that it would be nice to be able to provide Demo content in the wiki so that users who want to test drive XWiki can do so with existing content and more clearly see and understand the advantages that XWiki brings. For this, I’d propose to create a Demo Content extension (some AWM app + some blog posts + etc) and once we have it, recommend it on the Configuration Wizard. </similar idea>

WDYT?

Thanks -Vincent

...

On 08 Jun 2016, at 17:57, Denis Gervalle <[email protected]> wrote:

Well, very sorry to drop in so late in this discussion, but it was not obvious from the thread subject that your were discussing a major subject.

IMO, moving application that works currently on 6.x to the core, has no benefit for our users, it just introduce restrictions. It does not have any benefit for us either, it just require more backports. I do not understand this move at all for application that are not minimal requirements. I do not understand your point Vincent when you say that these applications are horizontal and obviously part of platform according to your "Executive summary".

Regarding the tour application, it is not require at all, it is just a nice helping tool that we want to ease newcomers, but experienced user will never need it. It could be exchanged for an alternative, and it is exactly the same kind of application than the blog that we are moving out. Regarding the CKEditor, do we consider that a WYSIWYG editor is required for a wiki to be a wiki ? IMO, WYSIWYG editor is not a requirement to use the platform, it is nice to have, but not required. I have use it very sparsely until now, and not having it would not have change much for me.

So, I currently do not see any benefit of moving these modules to platform, since these are already well living in contrib.

Your other point about reducing platform to the minimal runtime would cause platform to reduce to EM does not really looks like something that will happen. In theory, you are right, so XWiki would be even less featured then maven. But, I doubt you could reasonably use such a tools for anything useful. I doubt XWiki compare to maven. I doubt that horizontal module like security, logging, model, storage, etc… will ever be considered optional. Even a plain text editor is a minimal requirement to starts, else this is no more a wiki, and I even wonder what it is ? a tool that brings together arbitrary java module… looks weird. So no, the minimal runtime is definitely not just EM.

So, I really wonder what is the direction we are taking. I will not stop you with a veto, but I have the strong feeling these decisions are wrong. For the principle of not depending on contrib for our default user flavor, exchanging the blog app with the tour app, this does not make sens for me, sorry.

Thanks for reading.

On Wed, Jun 8, 2016 at 3:45 PM, Vincent Massol <[email protected]> wrote:

> FTR I’ve discussed internally with Thomas, Marius and Anca and we all > agreed that it makes sense to move The Tour app + CKEditor to the platform. > > There are various reasons but a very important one is simply the manpower > that it requires to maintain extensions on lots of XWiki versions and > currently the active devs on xwiki are not enough to do that. This is the > reason we dropped this strategy in the past and decided to release the > whole platform together with the same version. > > As part of this the technical debt is being increased since supporting > several versions and old versions means doing hacks. > > If you see another possibility that doesn’t require more work please raise > it here. > > We need to progress and have CKEditor and Tour bundled in 8.2M2(which is > already started) and thus, barring any negative comments, we’ll start the > move next week. > > Thanks > -Vincent > >> On 07 Jun 2016, at 15:39, Guillaume Delhumeau < > [email protected]> wrote: >> >> It also means to move the tour application in that old branches too. >> >> 2016-06-07 13:59 GMT+02:00 Vincent Massol <[email protected]>: >> >>> >>>> On 07 Jun 2016, at 10:27, Vincent Massol <[email protected]> wrote: >>>> >>>> >>>>> On 07 Jun 2016, at 09:37, Guillaume Delhumeau < >>> [email protected]> wrote: >>>>> >>>>> Moving Tour Application into platform makes sense to me (it becomes a >>>>> critical component and deserves a proper support). >>>> >>>> For me, it’s really about the definition of what the XWiki github org >>> represents. Right now with the new strategy == “Everything needed for > the >>> default XWiki runtime, a.k.a base/default flavor” (what we’ve been > calling >>> XE so far but that we’ll slim down a bit, for example by removing the > Blog >>> app and move it to contrib). >>>> >>>> Now we could still decide to have some flavor in contrib and have the >>> tour app included in that flavor but not in “the default XWiki > runtime”. In >>> practice this would mean promoting this flavor instead of the > base/default >>> flavor. The question will arise anyway when we next talk about other >>> flavors that we may want to have in contrib such a KB flavor, workgroup >>> flavor, web flavor, etc. >>>> >>>>> However, the current >>>>> application supports XWiki >= 6.4.1. By moving it to platform, we will >>> only >>>>> support the last XWiki version. >>>> >>>> This is a tough topic indeed. >>> >>> Actually in practice we would support not only the last XWiki version > but >>> also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we could > (we >>> still have a stable-6.4.x branch ATM that we were supposed to remove) > but >>> it would mean changing our support strategy to support more branches… > and >>> it means supporting the whole platform for 6.4.x, not just one > extension… >>> >>> Thanks >>> -Vincent >>> >>> >>>> For the tour there’s the solution of keeping it in contrib and >>> introducing a flavor but for CKEditor it’s harder to justify that it’s > not >>> part of the base flavor IMO but maybe it’s possible and we would offer > only >>> the wiki editor in the base flavor. Of course we could modify our >>> functional tests fwk to support running on various versions of the >>> dependencies and have CI builds to ensure that an extension works with > all >>> versions but it’s not perfect and it would mean that for the first time > we >>> would have code in the xwiki github org that would not use the latest >>> APIs/latest JDK features. >>>> >>>> The other option is Marius’s, i.e. accept that we hand-pick some >>> extensions from contrib that we bundle in the base/default flavor such > as >>> the Tour app, CKEditor integration, etc. In this case, we would just > need >>> to redefine what “xwiki github org” means. Saying “core component” would >>> not be enough, it would needs a more precise definition. >>>> >>>> Interesting topic ;) >>>> >>>> Any other option that we have? >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> 2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>: >>>>> >>>>>> >>>>>>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < >>>>>> [email protected]> wrote: >>>>>>> >>>>>>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol < [email protected]> >>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < >>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hello all, >>>>>>>>>> >>>>>>>>>> As it was decided already, a Homepage Tour have to be > implemented. >>>>>>>> However, >>>>>>>>>> no option regarding the place where the Tour Application should > be >>>>>>>> added as >>>>>>>>>> dependency was discussed. >>>>>>>>>> >>>>>>>>>> There are some possible options: >>>>>>>>>> 1) XWiki Enterprise >>>>>>>>>> 2) XWiki Platform Distribution >>>>>>>>>> 3) XWiki Platform Helper >>>>>>>>>> >>>>>>>>>> 4) Is there any option to have the Tour Application as a part of >>> the >>>>>>>> Core ? >>>>>>>>>> >>>>>>>>>> What would be the best way to include the Contrib applications in >>>>>> XWiki? >>>>>>>>>> >>>>>>>>> >>>>>>>>> On this topic (sorry if I hijack your thread) I was wondering why >>> don't >>>>>>>> we >>>>>>>>> have dependencies from platform/enterprise to contrib. We have > lots >>> of >>>>>>>>> third party dependencies, contrib could be considered as such. >>>>>> Moreover, >>>>>>>>> we're in the process of moving non-core (vertical) extensions out > of >>>>>>>>> platform to contrib. It would be a pity to move something from >>> contrib >>>>>> to >>>>>>>>> platform and then back to contrib. I have the same issue with the >>>>>>>> CKEditor >>>>>>>>> Integration extension. We want CKEditor as the default editor, >>> bundled >>>>>>>> with >>>>>>>>> the default distribution, but do we need to move it to platform? >>> Same >>>>>> for >>>>>>>>> the Welcome Tour. >>>>>>>> >>>>>>>> I’d personally not like this for the following reasons: >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> 1) I like that the XWiki runtime is all released at once with all >>>>>>>> extensions making it using the same versions and verified to work >>>>>> together. >>>>>>>> >>>>>>> >>>>>>> XWiki runtime has lots of third party dependencies. Bootstrap, Solr, >>>>>>> jQuery, just to name a few. I don't see how having the source code > in >>> our >>>>>>> repo (platform) makes a difference at runtime when the >>>>>>> integration/functional tests verify they work together. >>>>>> >>>>>> Because they don’t! :) Just check any extension in contrib and you’ll >>> see >>>>>> their func test (when they have some!) don’t test that they work with >>> the >>>>>> latest version of XWiki… >>>>>> >>>>>>> 2) Support. The XWiki runtime is supported by the XWiki Core Dev > Team. >>>>>>>> Extensions in contrib are not supported by the XWiki Core Dev Team. >>>>>>> >>>>>>> >>>>>>> So the FAQ application you moved out of platform is no longer >>> supported >>>>>> by >>>>>>> the XWiki Core Dev Team? >>>>>> >>>>>> Correct. >>>>>> >>>>>>> The extension page >>>>>>> > http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application >>>>>>> doesn't reflect this. >>>>>> >>>>>> I added my name to the list as a supporter. I’ve kept “XWiki Dev > Team” >>>>>> because it's a past authors and it wouldn’t make sense to remove it. >>> But >>>>>> yes it’s no longer officially supported by the XWiki Core Dev Team. >>>>>> >>>>>> Note that e.x.o doesn’t say who maintains a given extension, it just >>> says >>>>>> who participated to developing it ;) We’re currently missing the info >>> on >>>>>> whether the extension is actively supported and by whom. FTR > Confluence >>>>>> does this with a “supported” label that you can hover over and > provides >>>>>> info. For example: >>>>>> >>> >

https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

...

...

...

...

>>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> In addition xwiki-contrib is very open and anyone can make >>> modifications >>>>>>>> there and quality is thus harder to guarantee. >>>>>>>> >>>>>>>> We defined the xwiki github organization as containing horizontal >>>>>> modules, >>>>>>>> ie modules that can be required for any flavor and both CKEditor > and >>> the >>>>>>>> Tour Application fit the need. By opposition to vertical modules >>> which >>>>>> make >>>>>>>> sense only for some use cases (like the Meeting Manager app) and > not >>> by >>>>>>>> default in XE. We have the option of having flavors in contrib for >>>>>> those if >>>>>>>> we want though. For CKEditor it’s not a good thing since we’d like >>> it by >>>>>>>> default. >>>>>>>> >>>>>>>> One alternative (which I’m not fond of at all) would be to have >>> ckeditor >>>>>>>> as a separate git repo in the xwiki github organization. >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Marius >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alex

On 09 Jun 2016, at 14:55, Thomas Mortagne <[email protected]> wrote:

On Thu, Jun 9, 2016 at 2:17 PM, Vincent Massol <[email protected]> wrote:

...

...

On 09 Jun 2016, at 13:45, Eduard Moraru <[email protected]> wrote:

Hi,

As far as I can see, you want to make sure that the user installs the Tour,

Yep

...

for example, so that it is executed at the right time. However, why not let the flavor take care of this? Since the user will be choosing a flavor to install, it would also contain the tour (if it needs it) and everything will be set up.

That wouldn’t work for 2 reasons: * You only pick a flavor when you start with an empty wiki. So this isn’t the case for Jetty/HSQLDB distribution which is the most important packaging for people trying out XWiki. * We would have 2 flavors: the default one (and we would need somehow to prevent users from installing it, basically making the flavor useless) and the other one which would be the recommended one.

The goal of the idea I sent this morning is to have a single runtime flavor provided by the XWiki Core dev team that is generic but as useful as possible to users.

...

For additional extensions that the admin wants to install, we have the EM UI and we can have recommended extensions displayed there.

An extra step just for the recommended extensions is too much IMO and just gets in the way.

FTR This is exactly what happens when you install several softwares including Jenkins 2, IntelliJ IDEA and more.

...

We still control what the standard flavor contains (tour, CK, etc.) and we still control what (contrib) extensions to recommend in the EM UI. IMO, that is enough.

Ah I see what you mean. The other goal of the last proposal is to not have to bundle any extension (that’s really important IMO), ie. the XWiki Core Dev team doesn’t bundle any non xwiki github org code. Users can install contrib stuff at runtime and pick the version they want/need.

In addition this makes it possible for users to use the latest version of the extensions. For example: imagine that we release XWiki 8.2 with a dependency on CKEditor v1.7. Now, in the meantime CKEditor 1.8 is released. If we were providing a flavor for it in XWiki 8.2 then users wouldn’t be able to install version 1.8

This is true only for core jar extensions. CKEditor is a XAR.

Let me rephrase what I said because I haven’t used the correct wording. " In addition this makes it possible for users to *always* use the latest version of the extensions. For example: imagine that we release XWiki 8.2 with a dependency on CKEditor v1.7. Now, in the meantime CKEditor 1.8 is released. If we were providing a flavor for it in XWiki 8.2 then users would get CKEditor version 1.7 and thus they wouldn’t benefit from 1.8. They’d need to know to go the EM UI, run the updater, etc which is not something something trying out XWiki will know how to do. Thanks -Vincent

Thanks

...

-Vincent

...

Thanks, Eduard

On Thu, Jun 9, 2016 at 2:12 PM, Ecaterina Moraru (Valica) <[email protected]

...

wrote:

...

I think that if we are to have Recommended extensions inside e.x.o and EM, I would consider it a bit too much to have them also in DW. But maybe this is another discussion.

Thanks, Caty

On Thu, Jun 9, 2016 at 1:50 PM, Vincent Massol <[email protected]> wrote:

...

...

On 09 Jun 2016, at 11:15, Ecaterina Moraru (Valica) <[email protected]

wrote:

...

Hi,

Where are the Flavors in this proposal?

IMO Flavors don’t change; they’re still there and you still get them when you start with an empty wiki. When you start an empty wiki you pick the flavor you want and on the configuration screen, there are some

recommended

...

extensions that are proposed. I think that’s the difference: flavors are a fixed set of extensions. The Recommended extensions screen is just for optional stuff that you may want. If the recommended extensins are brought as part of the flavor (ie if they are already installed) then they won’t be suggested on the configuration screen.

Basically flavors are distribution. Once you install a distribution you can still install additional extensions by going to the Extension Manager. However we make the user’s file easier when he starts the first time by proposing some extensions.

This provides 2 advantages: * We bring extensions that we deem important but that are not maintainted by the xwiki core dev team to the user. He doesn’t need to discover the EM UI nor find out which extensions are super nice for me. * It allows to propose some extensions that need to run early in the process, such as the Tour (the user needs the Tour to know how to reach the EM UI ;)).

Another way of viewing this is that it’s a new feature of the EM/DW UI. The EM/DW module would provide a Recommended Extensions view as a Wizard when XWiki runtime starts the first time (and at each upgrade). Now what we would need to be careful about is not drowning the user under 50 recommended extensions or it would loose its power. I think this config wizard view should focus on Extensions that are super useful for getting started. Then later one the user could go to the EM UI and get a full list of Recommended Extensions, not just the one important for getting started.

WDYT?

Thanks -Vincent

...

Thanks, Caty

On Thu, Jun 9, 2016 at 12:01 PM, Vincent Massol <[email protected]> wrote:

> Hi everyone, > > Thanks for the replies. I’m listening of course to everyone and I’ve tried > in this mail to take all answers into account. > > First, let me state our current strategy and an alternative that I’ve been > thinking about this morning under my shower ;) > > Current Voted Strategy > ================== > > * Deliver an XWiki Runtime that is the best possible generic runtime (i.e. > most usable, most useful). > * As a consequence, remove all modules that vertical modules (i.e. that > are clearly not useful to all flavors), such as FAQ, Blog, etc. Move them > to xwiki-contrib > * I want to stress out that the current voted strategy is not to produce a > minimalist runtime > > New Strategy Proposal > ================== > > I’ve tried to reconcile all the use cases listed in this thread before and > I hope this proposal could be a good middle ground. In any case I found it > worth debating to see if it could work. > > Also note that one aspect that we must not forget (and that led to the > last proposal I sent on this thread) and that people tend to forget, is > the time it takes to support various versions of XE in an extension and the > manpower that exists in the xwiki community (don’t forget that everything > we do is a tradeoff; if you support another version of XE in an extension, > it means you’re not coding an important improvement or fixing an important > bug in the platform). > > So here’s the idea: > > * Change the purpose of the XWiki Github organization from the voted one > described above to be: Provide a minimalist runtime. > * Since working in this direction will not happen overnight, the idea > would be to very slowly take out modules, starting with obvious ones. > * The issue that this strategy raises is that users will not get a good > user experience since lots of things will be lacking and this is where my > new idea fills the gap: > ** The first time (or whenever you upgrade) your run the XWiki Runtime (be > it whether your run the HSQLDB/Jetty packaging or any other packaging) you > get a Configuration wizard > ** This Configuration Wizard suggest some recommended extensions that the > XWiki Core Dev Team hand-pick. We would start with 2: > *** Propose to the user to run a Tour to learn how to use XWiki (it would > install the Home Page Tour which depends on the Tour app) > *** Propose to the user to install the CKEDitor WYSIWYG editor (by default > we would only propose the wiki editor - We’ll need to get rid of the GWT > editor, probably make it an extension) > > Pros: > * The XWiki Core Dev Team continues to work on core stuff and as time > progresses we move out non core stuff > * This allows more people to contribute to the non-core stuff in the > community > * We control which extensions we want to recommend and thus we can always > only take the very good ones and thus control the quality of the initial > user experience > * We get a mechanism allowing our users to get non-xwiki core dev > team-supported extensions into the runtime (thus providing a good user > experience) while not bundling them into the default XWiki runtime flavor. > > Cons: > * The Tour and CKeditor extensions would still incur a higher cost of > support/maintenance (but since they’ve already done the code, it’s marginal > for the future and they’ll be able to abandon support for XWiki 6.x soon > IMO too - Basically they probably only need to support 2 or 2.5 cycle > versions). > > <similar idea> > Ludo mentioned (and I agree with him) that it would be nice to be able to > provide Demo content in the wiki so that users who want to test drive XWiki > can do so with existing content and more clearly see and understand the > advantages that XWiki brings. For this, I’d propose to create a Demo > Content extension (some AWM app + some blog posts + etc) and once we have > it, recommend it on the Configuration Wizard. > </similar idea> > > WDYT? > > Thanks > -Vincent > > >> On 08 Jun 2016, at 17:57, Denis Gervalle <[email protected]> wrote: >> >> Well, very sorry to drop in so late in this discussion, but it was not >> obvious from the thread subject that your were discussing a major > subject. >> >> IMO, moving application that works currently on 6.x to the core, has no >> benefit for our users, it just introduce restrictions. It does not have > any >> benefit for us either, it just require more backports. I do not > understand >> this move at all for application that are not minimal requirements. I do >> not understand your point Vincent when you say that these applications > are >> horizontal and obviously part of platform according to your "Executive >> summary". >> >> Regarding the tour application, it is not require at all, it is just a > nice >> helping tool that we want to ease newcomers, but experienced user will >> never need it. It could be exchanged for an alternative, and it is > exactly >> the same kind of application than the blog that we are moving out. >> Regarding the CKEditor, do we consider that a WYSIWYG editor is required >> for a wiki to be a wiki ? IMO, WYSIWYG editor is not a requirement to use >> the platform, it is nice to have, but not required. I have use it very >> sparsely until now, and not having it would not have change much for me. >> >> So, I currently do not see any benefit of moving these modules to > platform, >> since these are already well living in contrib. >> >> Your other point about reducing platform to the minimal runtime would > cause >> platform to reduce to EM does not really looks like something that will >> happen. In theory, you are right, so XWiki would be even less featured > then >> maven. But, I doubt you could reasonably use such a tools for anything >> useful. I doubt XWiki compare to maven. I doubt that horizontal module > like >> security, logging, model, storage, etc… will ever be considered optional. >> Even a plain text editor is a minimal requirement to starts, else this is >> no more a wiki, and I even wonder what it is ? a tool that brings > together >> arbitrary java module… looks weird. So no, the minimal runtime is >> definitely not just EM. >> >> So, I really wonder what is the direction we are taking. I will not stop >> you with a veto, but I have the strong feeling these decisions are wrong. >> For the principle of not depending on contrib for our default user > flavor, >> exchanging the blog app with the tour app, this does not make sens for > me, >> sorry. >> >> Thanks for reading. >> >> >> >> On Wed, Jun 8, 2016 at 3:45 PM, Vincent Massol <[email protected]> > wrote: >> >>> FTR I’ve discussed internally with Thomas, Marius and Anca and we all >>> agreed that it makes sense to move The Tour app + CKEditor to the > platform. >>> >>> There are various reasons but a very important one is simply the > manpower >>> that it requires to maintain extensions on lots of XWiki versions and >>> currently the active devs on xwiki are not enough to do that. This is > the >>> reason we dropped this strategy in the past and decided to release the >>> whole platform together with the same version. >>> >>> As part of this the technical debt is being increased since supporting >>> several versions and old versions means doing hacks. >>> >>> If you see another possibility that doesn’t require more work please > raise >>> it here. >>> >>> We need to progress and have CKEditor and Tour bundled in 8.2M2(which > is >>> already started) and thus, barring any negative comments, we’ll start > the >>> move next week. >>> >>> Thanks >>> -Vincent >>> >>>> On 07 Jun 2016, at 15:39, Guillaume Delhumeau < >>> [email protected]> wrote: >>>> >>>> It also means to move the tour application in that old branches too. >>>> >>>> 2016-06-07 13:59 GMT+02:00 Vincent Massol <[email protected]>: >>>> >>>>> >>>>>> On 07 Jun 2016, at 10:27, Vincent Massol <[email protected]> wrote: >>>>>> >>>>>> >>>>>>> On 07 Jun 2016, at 09:37, Guillaume Delhumeau < >>>>> [email protected]> wrote: >>>>>>> >>>>>>> Moving Tour Application into platform makes sense to me (it becomes > a >>>>>>> critical component and deserves a proper support). >>>>>> >>>>>> For me, it’s really about the definition of what the XWiki github org >>>>> represents. Right now with the new strategy == “Everything needed for >>> the >>>>> default XWiki runtime, a.k.a base/default flavor” (what we’ve been >>> calling >>>>> XE so far but that we’ll slim down a bit, for example by removing the >>> Blog >>>>> app and move it to contrib). >>>>>> >>>>>> Now we could still decide to have some flavor in contrib and have the >>>>> tour app included in that flavor but not in “the default XWiki >>> runtime”. In >>>>> practice this would mean promoting this flavor instead of the >>> base/default >>>>> flavor. The question will arise anyway when we next talk about other >>>>> flavors that we may want to have in contrib such a KB flavor, > workgroup >>>>> flavor, web flavor, etc. >>>>>> >>>>>>> However, the current >>>>>>> application supports XWiki >= 6.4.1. By moving it to platform, we > will >>>>> only >>>>>>> support the last XWiki version. >>>>>> >>>>>> This is a tough topic indeed. >>>>> >>>>> Actually in practice we would support not only the last XWiki version >>> but >>>>> also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we > could >>> (we >>>>> still have a stable-6.4.x branch ATM that we were supposed to remove) >>> but >>>>> it would mean changing our support strategy to support more branches… >>> and >>>>> it means supporting the whole platform for 6.4.x, not just one >>> extension… >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>> >>>>>> For the tour there’s the solution of keeping it in contrib and >>>>> introducing a flavor but for CKEditor it’s harder to justify that it’s >>> not >>>>> part of the base flavor IMO but maybe it’s possible and we would offer >>> only >>>>> the wiki editor in the base flavor. Of course we could modify our >>>>> functional tests fwk to support running on various versions of the >>>>> dependencies and have CI builds to ensure that an extension works with >>> all >>>>> versions but it’s not perfect and it would mean that for the first > time >>> we >>>>> would have code in the xwiki github org that would not use the latest >>>>> APIs/latest JDK features. >>>>>> >>>>>> The other option is Marius’s, i.e. accept that we hand-pick some >>>>> extensions from contrib that we bundle in the base/default flavor such >>> as >>>>> the Tour app, CKEditor integration, etc. In this case, we would just >>> need >>>>> to redefine what “xwiki github org” means. Saying “core component” > would >>>>> not be enough, it would needs a more precise definition. >>>>>> >>>>>> Interesting topic ;) >>>>>> >>>>>> Any other option that we have? >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> 2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>: >>>>>>> >>>>>>>> >>>>>>>>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < >>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol < > [email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello all, >>>>>>>>>>>> >>>>>>>>>>>> As it was decided already, a Homepage Tour have to be >>> implemented. >>>>>>>>>> However, >>>>>>>>>>>> no option regarding the place where the Tour Application should >>> be >>>>>>>>>> added as >>>>>>>>>>>> dependency was discussed. >>>>>>>>>>>> >>>>>>>>>>>> There are some possible options: >>>>>>>>>>>> 1) XWiki Enterprise >>>>>>>>>>>> 2) XWiki Platform Distribution >>>>>>>>>>>> 3) XWiki Platform Helper >>>>>>>>>>>> >>>>>>>>>>>> 4) Is there any option to have the Tour Application as a part > of >>>>> the >>>>>>>>>> Core ? >>>>>>>>>>>> >>>>>>>>>>>> What would be the best way to include the Contrib applications > in >>>>>>>> XWiki? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On this topic (sorry if I hijack your thread) I was wondering > why >>>>> don't >>>>>>>>>> we >>>>>>>>>>> have dependencies from platform/enterprise to contrib. We have >>> lots >>>>> of >>>>>>>>>>> third party dependencies, contrib could be considered as such. >>>>>>>> Moreover, >>>>>>>>>>> we're in the process of moving non-core (vertical) extensions > out >>> of >>>>>>>>>>> platform to contrib. It would be a pity to move something from >>>>> contrib >>>>>>>> to >>>>>>>>>>> platform and then back to contrib. I have the same issue with > the >>>>>>>>>> CKEditor >>>>>>>>>>> Integration extension. We want CKEditor as the default editor, >>>>> bundled >>>>>>>>>> with >>>>>>>>>>> the default distribution, but do we need to move it to platform? >>>>> Same >>>>>>>> for >>>>>>>>>>> the Welcome Tour. >>>>>>>>>> >>>>>>>>>> I’d personally not like this for the following reasons: >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> 1) I like that the XWiki runtime is all released at once with all >>>>>>>>>> extensions making it using the same versions and verified to work >>>>>>>> together. >>>>>>>>>> >>>>>>>>> >>>>>>>>> XWiki runtime has lots of third party dependencies. Bootstrap, > Solr, >>>>>>>>> jQuery, just to name a few. I don't see how having the source code >>> in >>>>> our >>>>>>>>> repo (platform) makes a difference at runtime when the >>>>>>>>> integration/functional tests verify they work together. >>>>>>>> >>>>>>>> Because they don’t! :) Just check any extension in contrib and > you’ll >>>>> see >>>>>>>> their func test (when they have some!) don’t test that they work > with >>>>> the >>>>>>>> latest version of XWiki… >>>>>>>> >>>>>>>>> 2) Support. The XWiki runtime is supported by the XWiki Core Dev >>> Team. >>>>>>>>>> Extensions in contrib are not supported by the XWiki Core Dev > Team. >>>>>>>>> >>>>>>>>> >>>>>>>>> So the FAQ application you moved out of platform is no longer >>>>> supported >>>>>>>> by >>>>>>>>> the XWiki Core Dev Team? >>>>>>>> >>>>>>>> Correct. >>>>>>>> >>>>>>>>> The extension page >>>>>>>>> >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application >>>>>>>>> doesn't reflect this. >>>>>>>> >>>>>>>> I added my name to the list as a supporter. I’ve kept “XWiki Dev >>> Team” >>>>>>>> because it's a past authors and it wouldn’t make sense to remove > it. >>>>> But >>>>>>>> yes it’s no longer officially supported by the XWiki Core Dev Team. >>>>>>>> >>>>>>>> Note that e.x.o doesn’t say who maintains a given extension, it > just >>>>> says >>>>>>>> who participated to developing it ;) We’re currently missing the > info >>>>> on >>>>>>>> whether the extension is actively supported and by whom. FTR >>> Confluence >>>>>>>> does this with a “supported” label that you can hover over and >>> provides >>>>>>>> info. For example: >>>>>>>> >>>>> >>> >

https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

...

...

>>>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> In addition xwiki-contrib is very open and anyone can make >>>>> modifications >>>>>>>>>> there and quality is thus harder to guarantee. >>>>>>>>>> >>>>>>>>>> We defined the xwiki github organization as containing horizontal >>>>>>>> modules, >>>>>>>>>> ie modules that can be required for any flavor and both CKEditor >>> and >>>>> the >>>>>>>>>> Tour Application fit the need. By opposition to vertical modules >>>>> which >>>>>>>> make >>>>>>>>>> sense only for some use cases (like the Meeting Manager app) and >>> not >>>>> by >>>>>>>>>> default in XE. We have the option of having flavors in contrib > for >>>>>>>> those if >>>>>>>>>> we want though. For CKEditor it’s not a good thing since we’d > like >>>>> it by >>>>>>>>>> default. >>>>>>>>>> >>>>>>>>>> One alternative (which I’m not fond of at all) would be to have >>>>> ckeditor >>>>>>>>>> as a separate git repo in the xwiki github organization. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> -Vincent >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Marius >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alex

Fine with me as long as there is a way for a Flavor to indicate that it does not want that recommended extensions DW step (probably some mechanism to let any flavor disable some DW step or add their own that following step would be the best probably, should not be too hard). It would not be disabled in the default flavor. On Thu, Jun 9, 2016 at 11:01 AM, Vincent Massol <[email protected]> wrote:

Hi everyone,

Thanks for the replies. I’m listening of course to everyone and I’ve tried in this mail to take all answers into account.

First, let me state our current strategy and an alternative that I’ve been thinking about this morning under my shower ;)

Current Voted Strategy ==================

* Deliver an XWiki Runtime that is the best possible generic runtime (i.e. most usable, most useful). * As a consequence, remove all modules that vertical modules (i.e. that are clearly not useful to all flavors), such as FAQ, Blog, etc. Move them to xwiki-contrib * I want to stress out that the current voted strategy is not to produce a minimalist runtime

New Strategy Proposal ==================

I’ve tried to reconcile all the use cases listed in this thread before and I hope this proposal could be a good middle ground. In any case I found it worth debating to see if it could work.

Also note that one aspect that we must not forget (and that led to the last proposal I sent on this thread) and that people tend to forget, is the time it takes to support various versions of XE in an extension and the manpower that exists in the xwiki community (don’t forget that everything we do is a tradeoff; if you support another version of XE in an extension, it means you’re not coding an important improvement or fixing an important bug in the platform).

So here’s the idea:

* Change the purpose of the XWiki Github organization from the voted one described above to be: Provide a minimalist runtime. * Since working in this direction will not happen overnight, the idea would be to very slowly take out modules, starting with obvious ones. * The issue that this strategy raises is that users will not get a good user experience since lots of things will be lacking and this is where my new idea fills the gap: ** The first time (or whenever you upgrade) your run the XWiki Runtime (be it whether your run the HSQLDB/Jetty packaging or any other packaging) you get a Configuration wizard ** This Configuration Wizard suggest some recommended extensions that the XWiki Core Dev Team hand-pick. We would start with 2: *** Propose to the user to run a Tour to learn how to use XWiki (it would install the Home Page Tour which depends on the Tour app) *** Propose to the user to install the CKEDitor WYSIWYG editor (by default we would only propose the wiki editor - We’ll need to get rid of the GWT editor, probably make it an extension)

Pros: * The XWiki Core Dev Team continues to work on core stuff and as time progresses we move out non core stuff * This allows more people to contribute to the non-core stuff in the community * We control which extensions we want to recommend and thus we can always only take the very good ones and thus control the quality of the initial user experience * We get a mechanism allowing our users to get non-xwiki core dev team-supported extensions into the runtime (thus providing a good user experience) while not bundling them into the default XWiki runtime flavor.

Cons: * The Tour and CKeditor extensions would still incur a higher cost of support/maintenance (but since they’ve already done the code, it’s marginal for the future and they’ll be able to abandon support for XWiki 6.x soon IMO too - Basically they probably only need to support 2 or 2.5 cycle versions).

<similar idea> Ludo mentioned (and I agree with him) that it would be nice to be able to provide Demo content in the wiki so that users who want to test drive XWiki can do so with existing content and more clearly see and understand the advantages that XWiki brings. For this, I’d propose to create a Demo Content extension (some AWM app + some blog posts + etc) and once we have it, recommend it on the Configuration Wizard. </similar idea>

WDYT?

Thanks -Vincent

...

On 08 Jun 2016, at 17:57, Denis Gervalle <[email protected]> wrote:

Well, very sorry to drop in so late in this discussion, but it was not obvious from the thread subject that your were discussing a major subject.

IMO, moving application that works currently on 6.x to the core, has no benefit for our users, it just introduce restrictions. It does not have any benefit for us either, it just require more backports. I do not understand this move at all for application that are not minimal requirements. I do not understand your point Vincent when you say that these applications are horizontal and obviously part of platform according to your "Executive summary".

Regarding the tour application, it is not require at all, it is just a nice helping tool that we want to ease newcomers, but experienced user will never need it. It could be exchanged for an alternative, and it is exactly the same kind of application than the blog that we are moving out. Regarding the CKEditor, do we consider that a WYSIWYG editor is required for a wiki to be a wiki ? IMO, WYSIWYG editor is not a requirement to use the platform, it is nice to have, but not required. I have use it very sparsely until now, and not having it would not have change much for me.

So, I currently do not see any benefit of moving these modules to platform, since these are already well living in contrib.

Your other point about reducing platform to the minimal runtime would cause platform to reduce to EM does not really looks like something that will happen. In theory, you are right, so XWiki would be even less featured then maven. But, I doubt you could reasonably use such a tools for anything useful. I doubt XWiki compare to maven. I doubt that horizontal module like security, logging, model, storage, etc… will ever be considered optional. Even a plain text editor is a minimal requirement to starts, else this is no more a wiki, and I even wonder what it is ? a tool that brings together arbitrary java module… looks weird. So no, the minimal runtime is definitely not just EM.

So, I really wonder what is the direction we are taking. I will not stop you with a veto, but I have the strong feeling these decisions are wrong. For the principle of not depending on contrib for our default user flavor, exchanging the blog app with the tour app, this does not make sens for me, sorry.

Thanks for reading.

On Wed, Jun 8, 2016 at 3:45 PM, Vincent Massol <[email protected]> wrote:

...

FTR I’ve discussed internally with Thomas, Marius and Anca and we all agreed that it makes sense to move The Tour app + CKEditor to the platform.

There are various reasons but a very important one is simply the manpower that it requires to maintain extensions on lots of XWiki versions and currently the active devs on xwiki are not enough to do that. This is the reason we dropped this strategy in the past and decided to release the whole platform together with the same version.

As part of this the technical debt is being increased since supporting several versions and old versions means doing hacks.

If you see another possibility that doesn’t require more work please raise it here.

We need to progress and have CKEditor and Tour bundled in 8.2M2(which is already started) and thus, barring any negative comments, we’ll start the move next week.

Thanks -Vincent

...

On 07 Jun 2016, at 15:39, Guillaume Delhumeau < [email protected]> wrote:

It also means to move the tour application in that old branches too.

2016-06-07 13:59 GMT+02:00 Vincent Massol <[email protected]>:

...

...

On 07 Jun 2016, at 10:27, Vincent Massol <[email protected]> wrote:

> On 07 Jun 2016, at 09:37, Guillaume Delhumeau < [email protected]> wrote: > > Moving Tour Application into platform makes sense to me (it becomes a > critical component and deserves a proper support).

For me, it’s really about the definition of what the XWiki github org represents. Right now with the new strategy == “Everything needed for

the

...

default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling XE so far but that we’ll slim down a bit, for example by removing the Blog app and move it to contrib).

...

Now we could still decide to have some flavor in contrib and have the

tour app included in that flavor but not in “the default XWiki runtime”. In practice this would mean promoting this flavor instead of the base/default flavor. The question will arise anyway when we next talk about other flavors that we may want to have in contrib such a KB flavor, workgroup flavor, web flavor, etc.

...

> However, the current > application supports XWiki >= 6.4.1. By moving it to platform, we will

only

...

> support the last XWiki version.

This is a tough topic indeed.

Actually in practice we would support not only the last XWiki version but also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we could (we still have a stable-6.4.x branch ATM that we were supposed to remove) but it would mean changing our support strategy to support more branches… and it means supporting the whole platform for 6.4.x, not just one extension…

Thanks -Vincent

...

For the tour there’s the solution of keeping it in contrib and introducing a flavor but for CKEditor it’s harder to justify that it’s not part of the base flavor IMO but maybe it’s possible and we would offer only the wiki editor in the base flavor. Of course we could modify our functional tests fwk to support running on various versions of the dependencies and have CI builds to ensure that an extension works with all versions but it’s not perfect and it would mean that for the first time we would have code in the xwiki github org that would not use the latest APIs/latest JDK features.

The other option is Marius’s, i.e. accept that we hand-pick some extensions from contrib that we bundle in the base/default flavor such as the Tour app, CKEditor integration, etc. In this case, we would just need to redefine what “xwiki github org” means. Saying “core component” would not be enough, it would needs a more precise definition.

Interesting topic ;)

Any other option that we have?

Thanks -Vincent

> 2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>: > >> >>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < >> [email protected]> wrote: >>> >>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol <[email protected]> >> wrote: >>> >>>> >>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < >>>> [email protected]> wrote: >>>>> >>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >>>>> [email protected]> wrote: >>>>> >>>>>> Hello all, >>>>>> >>>>>> As it was decided already, a Homepage Tour have to be implemented. >>>> However, >>>>>> no option regarding the place where the Tour Application should be >>>> added as >>>>>> dependency was discussed. >>>>>> >>>>>> There are some possible options: >>>>>> 1) XWiki Enterprise >>>>>> 2) XWiki Platform Distribution >>>>>> 3) XWiki Platform Helper >>>>>> >>>>>> 4) Is there any option to have the Tour Application as a part of the >>>> Core ? >>>>>> >>>>>> What would be the best way to include the Contrib applications in >> XWiki? >>>>>> >>>>> >>>>> On this topic (sorry if I hijack your thread) I was wondering why don't >>>> we >>>>> have dependencies from platform/enterprise to contrib. We have lots of >>>>> third party dependencies, contrib could be considered as such. >> Moreover, >>>>> we're in the process of moving non-core (vertical) extensions out of >>>>> platform to contrib. It would be a pity to move something from contrib >> to >>>>> platform and then back to contrib. I have the same issue with the >>>> CKEditor >>>>> Integration extension. We want CKEditor as the default editor, bundled >>>> with >>>>> the default distribution, but do we need to move it to platform? Same >> for >>>>> the Welcome Tour. >>>> >>>> I’d personally not like this for the following reasons: >>>> >>>> >>> >>>> 1) I like that the XWiki runtime is all released at once with all >>>> extensions making it using the same versions and verified to work >> together. >>>> >>> >>> XWiki runtime has lots of third party dependencies. Bootstrap, Solr, >>> jQuery, just to name a few. I don't see how having the source code in our >>> repo (platform) makes a difference at runtime when the >>> integration/functional tests verify they work together. >> >> Because they don’t! :) Just check any extension in contrib and you’ll see >> their func test (when they have some!) don’t test that they work with the >> latest version of XWiki… >> >>> 2) Support. The XWiki runtime is supported by the XWiki Core Dev Team. >>>> Extensions in contrib are not supported by the XWiki Core Dev Team. >>> >>> >>> So the FAQ application you moved out of platform is no longer supported >> by >>> the XWiki Core Dev Team? >> >> Correct. >> >>> The extension page >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application >>> doesn't reflect this. >> >> I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” >> because it's a past authors and it wouldn’t make sense to remove it. But >> yes it’s no longer officially supported by the XWiki Core Dev Team. >> >> Note that e.x.o doesn’t say who maintains a given extension, it just says >> who participated to developing it ;) We’re currently missing the info on >> whether the extension is actively supported and by whom. FTR Confluence >> does this with a “supported” label that you can hover over and provides >> info. For example: >>

https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

...

...

>> >> Thanks >> -Vincent >> >>> In addition xwiki-contrib is very open and anyone can make modifications >>>> there and quality is thus harder to guarantee. >>>> >>>> We defined the xwiki github organization as containing horizontal >> modules, >>>> ie modules that can be required for any flavor and both CKEditor and the >>>> Tour Application fit the need. By opposition to vertical modules which >> make >>>> sense only for some use cases (like the Meeting Manager app) and not by >>>> default in XE. We have the option of having flavors in contrib for >> those if >>>> we want though. For CKEditor it’s not a good thing since we’d like it by >>>> default. >>>> >>>> One alternative (which I’m not fond of at all) would be to have ckeditor >>>> as a separate git repo in the xwiki github organization. >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> Thanks, >>>>> Marius >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Alex

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

Since my last proposal didn’t get a consensus, let’s restart the discussion in more general terms: Current Strategy ============= We defined it in the "xwiki core” thread (source: http://markmail.org/message/w6veilqhhnjqcw3e): " 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, 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 " Right now the goal of the XWiki Platform is to provide the **most usable generic runtime possible**. According to this definition the Tour and CKEditor are both clearly platform modules. Note that the goal of flavors right now is to provide verticals. It’s not to provide additional extensions that make the generic XWiki runtime more usable. Future Options ============ There are only 2 options that are different from the current one and that I can imagine: A) Keep the Tour application and CKEditor extension outside of XWiki Platform. The consequence is that the current strategy doesn’t apply anymore and we would need a new definition of XWiki Platform. One that I could see would be “a minimally usable generic runtime”, which is very undefined. For example, is the Annotation feature part of a minimal distribution. Answer: no. Actually we could even question if the EM is needed for a minimally usable runtime (first versions of XWiki were usable and didn’t have the EM). Activity Stream? AppWithinMinutes? Chart feature? So we would need to define clearly what we call a minimally usable runtime. B) Move the Tour application and CKEditor extension inside XWiki Platform but start having different version/release lifecycle for some extensions. If we do this for the Tour or CK then there’s no reason not to do it for other extensions and very quickly we go back to what we were doing 6-8 years ago where it was a major PITA to do any release and to validate what extension version was working with what other extension. For me B) is not a good option and neither if A) unless we find a way to clearly define it. My worry for A) is that it’s easy to say that we want a minimal runtime and this would mean moving a LOT of modules outside of platform and into contrib, which would mean a lot more work to maintain/release them (each module would have its release cycle). Releasing platform would becomes simpler (less stuff to build) but release the default flavor (in contrib) would become a major pain. And also, who would do it since there’s no notion of Release Manager for contrib. Any dev of contrib could release a new version of the default flavor and thus change what the default XWiki runtime is. I feel we need to control what the default XWiki runtime is and that should be the XWiki Core Dev Team who does this. So at this point I believe that we need to keep the default flavor in platform and I don’t see any viable option other than the current strategy. @Denis: if you’re in favor of A) please let us know how you’d implement it in detail and how you’d answer the challenges I raised. Thanks -Vincent

On 09 Jun 2016, at 11:01, Vincent Massol <[email protected]> wrote:

Hi everyone,

Thanks for the replies. I’m listening of course to everyone and I’ve tried in this mail to take all answers into account.

First, let me state our current strategy and an alternative that I’ve been thinking about this morning under my shower ;)

Current Voted Strategy ==================

* Deliver an XWiki Runtime that is the best possible generic runtime (i.e. most usable, most useful). * As a consequence, remove all modules that vertical modules (i.e. that are clearly not useful to all flavors), such as FAQ, Blog, etc. Move them to xwiki-contrib * I want to stress out that the current voted strategy is not to produce a minimalist runtime

New Strategy Proposal ==================

I’ve tried to reconcile all the use cases listed in this thread before and I hope this proposal could be a good middle ground. In any case I found it worth debating to see if it could work.

Also note that one aspect that we must not forget (and that led to the last proposal I sent on this thread) and that people tend to forget, is the time it takes to support various versions of XE in an extension and the manpower that exists in the xwiki community (don’t forget that everything we do is a tradeoff; if you support another version of XE in an extension, it means you’re not coding an important improvement or fixing an important bug in the platform).

So here’s the idea:

* Change the purpose of the XWiki Github organization from the voted one described above to be: Provide a minimalist runtime. * Since working in this direction will not happen overnight, the idea would be to very slowly take out modules, starting with obvious ones. * The issue that this strategy raises is that users will not get a good user experience since lots of things will be lacking and this is where my new idea fills the gap: ** The first time (or whenever you upgrade) your run the XWiki Runtime (be it whether your run the HSQLDB/Jetty packaging or any other packaging) you get a Configuration wizard ** This Configuration Wizard suggest some recommended extensions that the XWiki Core Dev Team hand-pick. We would start with 2: *** Propose to the user to run a Tour to learn how to use XWiki (it would install the Home Page Tour which depends on the Tour app) *** Propose to the user to install the CKEDitor WYSIWYG editor (by default we would only propose the wiki editor - We’ll need to get rid of the GWT editor, probably make it an extension)

Pros: * The XWiki Core Dev Team continues to work on core stuff and as time progresses we move out non core stuff * This allows more people to contribute to the non-core stuff in the community * We control which extensions we want to recommend and thus we can always only take the very good ones and thus control the quality of the initial user experience * We get a mechanism allowing our users to get non-xwiki core dev team-supported extensions into the runtime (thus providing a good user experience) while not bundling them into the default XWiki runtime flavor.

Cons: * The Tour and CKeditor extensions would still incur a higher cost of support/maintenance (but since they’ve already done the code, it’s marginal for the future and they’ll be able to abandon support for XWiki 6.x soon IMO too - Basically they probably only need to support 2 or 2.5 cycle versions).

<similar idea> Ludo mentioned (and I agree with him) that it would be nice to be able to provide Demo content in the wiki so that users who want to test drive XWiki can do so with existing content and more clearly see and understand the advantages that XWiki brings. For this, I’d propose to create a Demo Content extension (some AWM app + some blog posts + etc) and once we have it, recommend it on the Configuration Wizard. </similar idea>

WDYT?

Thanks -Vincent

...

On 08 Jun 2016, at 17:57, Denis Gervalle <[email protected]> wrote:

Well, very sorry to drop in so late in this discussion, but it was not obvious from the thread subject that your were discussing a major subject.

IMO, moving application that works currently on 6.x to the core, has no benefit for our users, it just introduce restrictions. It does not have any benefit for us either, it just require more backports. I do not understand this move at all for application that are not minimal requirements. I do not understand your point Vincent when you say that these applications are horizontal and obviously part of platform according to your "Executive summary".

Regarding the tour application, it is not require at all, it is just a nice helping tool that we want to ease newcomers, but experienced user will never need it. It could be exchanged for an alternative, and it is exactly the same kind of application than the blog that we are moving out. Regarding the CKEditor, do we consider that a WYSIWYG editor is required for a wiki to be a wiki ? IMO, WYSIWYG editor is not a requirement to use the platform, it is nice to have, but not required. I have use it very sparsely until now, and not having it would not have change much for me.

So, I currently do not see any benefit of moving these modules to platform, since these are already well living in contrib.

Your other point about reducing platform to the minimal runtime would cause platform to reduce to EM does not really looks like something that will happen. In theory, you are right, so XWiki would be even less featured then maven. But, I doubt you could reasonably use such a tools for anything useful. I doubt XWiki compare to maven. I doubt that horizontal module like security, logging, model, storage, etc… will ever be considered optional. Even a plain text editor is a minimal requirement to starts, else this is no more a wiki, and I even wonder what it is ? a tool that brings together arbitrary java module… looks weird. So no, the minimal runtime is definitely not just EM.

So, I really wonder what is the direction we are taking. I will not stop you with a veto, but I have the strong feeling these decisions are wrong. For the principle of not depending on contrib for our default user flavor, exchanging the blog app with the tour app, this does not make sens for me, sorry.

Thanks for reading.

On Wed, Jun 8, 2016 at 3:45 PM, Vincent Massol <[email protected]> wrote:

...

FTR I’ve discussed internally with Thomas, Marius and Anca and we all agreed that it makes sense to move The Tour app + CKEditor to the platform.

There are various reasons but a very important one is simply the manpower that it requires to maintain extensions on lots of XWiki versions and currently the active devs on xwiki are not enough to do that. This is the reason we dropped this strategy in the past and decided to release the whole platform together with the same version.

As part of this the technical debt is being increased since supporting several versions and old versions means doing hacks.

If you see another possibility that doesn’t require more work please raise it here.

We need to progress and have CKEditor and Tour bundled in 8.2M2(which is already started) and thus, barring any negative comments, we’ll start the move next week.

Thanks -Vincent

...

On 07 Jun 2016, at 15:39, Guillaume Delhumeau < [email protected]> wrote:

It also means to move the tour application in that old branches too.

2016-06-07 13:59 GMT+02:00 Vincent Massol <[email protected]>:

...

...

On 07 Jun 2016, at 10:27, Vincent Massol <[email protected]> wrote:

> On 07 Jun 2016, at 09:37, Guillaume Delhumeau < [email protected]> wrote: > > Moving Tour Application into platform makes sense to me (it becomes a > critical component and deserves a proper support).

For me, it’s really about the definition of what the XWiki github org represents. Right now with the new strategy == “Everything needed for

the

...

default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling XE so far but that we’ll slim down a bit, for example by removing the Blog app and move it to contrib).

...

Now we could still decide to have some flavor in contrib and have the

tour app included in that flavor but not in “the default XWiki runtime”. In practice this would mean promoting this flavor instead of the base/default flavor. The question will arise anyway when we next talk about other flavors that we may want to have in contrib such a KB flavor, workgroup flavor, web flavor, etc.

...

> However, the current > application supports XWiki >= 6.4.1. By moving it to platform, we will

only

...

> support the last XWiki version.

This is a tough topic indeed.

Actually in practice we would support not only the last XWiki version but also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we could (we still have a stable-6.4.x branch ATM that we were supposed to remove) but it would mean changing our support strategy to support more branches… and it means supporting the whole platform for 6.4.x, not just one extension…

Thanks -Vincent

...

For the tour there’s the solution of keeping it in contrib and introducing a flavor but for CKEditor it’s harder to justify that it’s not part of the base flavor IMO but maybe it’s possible and we would offer only the wiki editor in the base flavor. Of course we could modify our functional tests fwk to support running on various versions of the dependencies and have CI builds to ensure that an extension works with all versions but it’s not perfect and it would mean that for the first time we would have code in the xwiki github org that would not use the latest APIs/latest JDK features.

The other option is Marius’s, i.e. accept that we hand-pick some extensions from contrib that we bundle in the base/default flavor such as the Tour app, CKEditor integration, etc. In this case, we would just need to redefine what “xwiki github org” means. Saying “core component” would not be enough, it would needs a more precise definition.

Interesting topic ;)

Any other option that we have?

Thanks -Vincent

> 2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>: > >> >>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < >> [email protected]> wrote: >>> >>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol <[email protected]> >> wrote: >>> >>>> >>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < >>>> [email protected]> wrote: >>>>> >>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >>>>> [email protected]> wrote: >>>>> >>>>>> Hello all, >>>>>> >>>>>> As it was decided already, a Homepage Tour have to be implemented. >>>> However, >>>>>> no option regarding the place where the Tour Application should be >>>> added as >>>>>> dependency was discussed. >>>>>> >>>>>> There are some possible options: >>>>>> 1) XWiki Enterprise >>>>>> 2) XWiki Platform Distribution >>>>>> 3) XWiki Platform Helper >>>>>> >>>>>> 4) Is there any option to have the Tour Application as a part of the >>>> Core ? >>>>>> >>>>>> What would be the best way to include the Contrib applications in >> XWiki? >>>>>> >>>>> >>>>> On this topic (sorry if I hijack your thread) I was wondering why don't >>>> we >>>>> have dependencies from platform/enterprise to contrib. We have lots of >>>>> third party dependencies, contrib could be considered as such. >> Moreover, >>>>> we're in the process of moving non-core (vertical) extensions out of >>>>> platform to contrib. It would be a pity to move something from contrib >> to >>>>> platform and then back to contrib. I have the same issue with the >>>> CKEditor >>>>> Integration extension. We want CKEditor as the default editor, bundled >>>> with >>>>> the default distribution, but do we need to move it to platform? Same >> for >>>>> the Welcome Tour. >>>> >>>> I’d personally not like this for the following reasons: >>>> >>>> >>> >>>> 1) I like that the XWiki runtime is all released at once with all >>>> extensions making it using the same versions and verified to work >> together. >>>> >>> >>> XWiki runtime has lots of third party dependencies. Bootstrap, Solr, >>> jQuery, just to name a few. I don't see how having the source code in our >>> repo (platform) makes a difference at runtime when the >>> integration/functional tests verify they work together. >> >> Because they don’t! :) Just check any extension in contrib and you’ll see >> their func test (when they have some!) don’t test that they work with the >> latest version of XWiki… >> >>> 2) Support. The XWiki runtime is supported by the XWiki Core Dev Team. >>>> Extensions in contrib are not supported by the XWiki Core Dev Team. >>> >>> >>> So the FAQ application you moved out of platform is no longer supported >> by >>> the XWiki Core Dev Team? >> >> Correct. >> >>> The extension page >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application >>> doesn't reflect this. >> >> I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” >> because it's a past authors and it wouldn’t make sense to remove it. But >> yes it’s no longer officially supported by the XWiki Core Dev Team. >> >> Note that e.x.o doesn’t say who maintains a given extension, it just says >> who participated to developing it ;) We’re currently missing the info on >> whether the extension is actively supported and by whom. FTR Confluence >> does this with a “supported” label that you can hover over and provides >> info. For example: >>

https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

...

...

>> >> Thanks >> -Vincent >> >>> In addition xwiki-contrib is very open and anyone can make modifications >>>> there and quality is thus harder to guarantee. >>>> >>>> We defined the xwiki github organization as containing horizontal >> modules, >>>> ie modules that can be required for any flavor and both CKEditor and the >>>> Tour Application fit the need. By opposition to vertical modules which >> make >>>> sense only for some use cases (like the Meeting Manager app) and not by >>>> default in XE. We have the option of having flavors in contrib for >> those if >>>> we want though. For CKEditor it’s not a good thing since we’d like it by >>>> default. >>>> >>>> One alternative (which I’m not fond of at all) would be to have ckeditor >>>> as a separate git repo in the xwiki github organization. >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> Thanks, >>>>> Marius >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Alex

Sounds good enough. On Mon, Jun 20, 2016 at 12:48 PM, Vincent Massol <[email protected]> wrote:

Ok so I’ve brainstormed with Denis and we worked on option A) below.

Here’s what we could do:

* Make XWiki Github org == minimal runtime, where minimal means “basic wiki” (page edition, history, linking, wiki markup, etc). The notion of “basic wiki” would need to be better defined but this can be done later on. * Provide a "Base Flavor" which corresponds to this “basic wiki”, as part of xwiki-platform (this would be xwiki-platform-distribution). * Provide another flavor, the "Default Flavor” which would add some hand-picked third-party extensions (i.e. from contrib) such as the Tour app and CKEditor (to start with, we could also add the markdown syntax for example which is one of the most asked syntaxes). Note that this Default Flavor would actually be a “replacement" of xwiki-enterprise. * The Default Flavor would have at least the same release cycle as the base flavor but it could have more releases (if some of the bundled third-party extensions has some important bug fixes or new features that we want to offer quickly without waiting for the next base flavor release). * The consequence is that the XWiki Dev Team would need to be a bit more careful to monitor the quality of bundled third-party extensions in contrib (check commits, do some smoke testing, etc). Note that the goal of the Default flavor would not be to offer verticals (for this there should be some contrib flavors) and thus it wouldn’t bundle a lot of third-party extensions. Basically we’ll need to validate the version of those third-party extensions that include in the flavor.

My POV is that globally this would offer more flexibility for our users (they’ll be able to install extensions such as CK and Tour in older XWiki versions and they’ll get more frequent releases) at the cost of some overhead to develop extensions that work in several versions. The dev team is pretty small and thus it means developing a bit less fast but it’s probably as important, if not more important, to make the code we develop available in older xwiki versions, as XWiki gains traction.

WDYT?

Thanks -Vincent

...

On 20 Jun 2016, at 09:41, Vincent Massol <[email protected]> wrote:

Since my last proposal didn’t get a consensus, let’s restart the discussion in more general terms:

Current Strategy =============

We defined it in the "xwiki core” thread (source: http://markmail.org/message/w6veilqhhnjqcw3e):

" 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, 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 "

Right now the goal of the XWiki Platform is to provide the **most usable generic runtime possible**.

According to this definition the Tour and CKEditor are both clearly platform modules.

Note that the goal of flavors right now is to provide verticals. It’s not to provide additional extensions that make the generic XWiki runtime more usable.

Future Options ============

There are only 2 options that are different from the current one and that I can imagine:

A) Keep the Tour application and CKEditor extension outside of XWiki Platform. The consequence is that the current strategy doesn’t apply anymore and we would need a new definition of XWiki Platform. One that I could see would be “a minimally usable generic runtime”, which is very undefined. For example, is the Annotation feature part of a minimal distribution. Answer: no. Actually we could even question if the EM is needed for a minimally usable runtime (first versions of XWiki were usable and didn’t have the EM). Activity Stream? AppWithinMinutes? Chart feature? So we would need to define clearly what we call a minimally usable runtime.

B) Move the Tour application and CKEditor extension inside XWiki Platform but start having different version/release lifecycle for some extensions. If we do this for the Tour or CK then there’s no reason not to do it for other extensions and very quickly we go back to what we were doing 6-8 years ago where it was a major PITA to do any release and to validate what extension version was working with what other extension.

For me B) is not a good option and neither if A) unless we find a way to clearly define it.

My worry for A) is that it’s easy to say that we want a minimal runtime and this would mean moving a LOT of modules outside of platform and into contrib, which would mean a lot more work to maintain/release them (each module would have its release cycle). Releasing platform would becomes simpler (less stuff to build) but release the default flavor (in contrib) would become a major pain. And also, who would do it since there’s no notion of Release Manager for contrib. Any dev of contrib could release a new version of the default flavor and thus change what the default XWiki runtime is. I feel we need to control what the default XWiki runtime is and that should be the XWiki Core Dev Team who does this.

So at this point I believe that we need to keep the default flavor in platform and I don’t see any viable option other than the current strategy.

@Denis: if you’re in favor of A) please let us know how you’d implement it in detail and how you’d answer the challenges I raised.

Thanks -Vincent

...

On 09 Jun 2016, at 11:01, Vincent Massol <[email protected]> wrote:

Hi everyone,

Thanks for the replies. I’m listening of course to everyone and I’ve tried in this mail to take all answers into account.

First, let me state our current strategy and an alternative that I’ve been thinking about this morning under my shower ;)

Current Voted Strategy ==================

* Deliver an XWiki Runtime that is the best possible generic runtime (i.e. most usable, most useful). * As a consequence, remove all modules that vertical modules (i.e. that are clearly not useful to all flavors), such as FAQ, Blog, etc. Move them to xwiki-contrib * I want to stress out that the current voted strategy is not to produce a minimalist runtime

New Strategy Proposal ==================

I’ve tried to reconcile all the use cases listed in this thread before and I hope this proposal could be a good middle ground. In any case I found it worth debating to see if it could work.

Also note that one aspect that we must not forget (and that led to the last proposal I sent on this thread) and that people tend to forget, is the time it takes to support various versions of XE in an extension and the manpower that exists in the xwiki community (don’t forget that everything we do is a tradeoff; if you support another version of XE in an extension, it means you’re not coding an important improvement or fixing an important bug in the platform).

So here’s the idea:

* Change the purpose of the XWiki Github organization from the voted one described above to be: Provide a minimalist runtime. * Since working in this direction will not happen overnight, the idea would be to very slowly take out modules, starting with obvious ones. * The issue that this strategy raises is that users will not get a good user experience since lots of things will be lacking and this is where my new idea fills the gap: ** The first time (or whenever you upgrade) your run the XWiki Runtime (be it whether your run the HSQLDB/Jetty packaging or any other packaging) you get a Configuration wizard ** This Configuration Wizard suggest some recommended extensions that the XWiki Core Dev Team hand-pick. We would start with 2: *** Propose to the user to run a Tour to learn how to use XWiki (it would install the Home Page Tour which depends on the Tour app) *** Propose to the user to install the CKEDitor WYSIWYG editor (by default we would only propose the wiki editor - We’ll need to get rid of the GWT editor, probably make it an extension)

Pros: * The XWiki Core Dev Team continues to work on core stuff and as time progresses we move out non core stuff * This allows more people to contribute to the non-core stuff in the community * We control which extensions we want to recommend and thus we can always only take the very good ones and thus control the quality of the initial user experience * We get a mechanism allowing our users to get non-xwiki core dev team-supported extensions into the runtime (thus providing a good user experience) while not bundling them into the default XWiki runtime flavor.

Cons: * The Tour and CKeditor extensions would still incur a higher cost of support/maintenance (but since they’ve already done the code, it’s marginal for the future and they’ll be able to abandon support for XWiki 6.x soon IMO too - Basically they probably only need to support 2 or 2.5 cycle versions).

<similar idea> Ludo mentioned (and I agree with him) that it would be nice to be able to provide Demo content in the wiki so that users who want to test drive XWiki can do so with existing content and more clearly see and understand the advantages that XWiki brings. For this, I’d propose to create a Demo Content extension (some AWM app + some blog posts + etc) and once we have it, recommend it on the Configuration Wizard. </similar idea>

WDYT?

Thanks -Vincent

...

On 08 Jun 2016, at 17:57, Denis Gervalle <[email protected]> wrote:

Well, very sorry to drop in so late in this discussion, but it was not obvious from the thread subject that your were discussing a major subject.

IMO, moving application that works currently on 6.x to the core, has no benefit for our users, it just introduce restrictions. It does not have any benefit for us either, it just require more backports. I do not understand this move at all for application that are not minimal requirements. I do not understand your point Vincent when you say that these applications are horizontal and obviously part of platform according to your "Executive summary".

Regarding the tour application, it is not require at all, it is just a nice helping tool that we want to ease newcomers, but experienced user will never need it. It could be exchanged for an alternative, and it is exactly the same kind of application than the blog that we are moving out. Regarding the CKEditor, do we consider that a WYSIWYG editor is required for a wiki to be a wiki ? IMO, WYSIWYG editor is not a requirement to use the platform, it is nice to have, but not required. I have use it very sparsely until now, and not having it would not have change much for me.

So, I currently do not see any benefit of moving these modules to platform, since these are already well living in contrib.

Your other point about reducing platform to the minimal runtime would cause platform to reduce to EM does not really looks like something that will happen. In theory, you are right, so XWiki would be even less featured then maven. But, I doubt you could reasonably use such a tools for anything useful. I doubt XWiki compare to maven. I doubt that horizontal module like security, logging, model, storage, etc… will ever be considered optional. Even a plain text editor is a minimal requirement to starts, else this is no more a wiki, and I even wonder what it is ? a tool that brings together arbitrary java module… looks weird. So no, the minimal runtime is definitely not just EM.

So, I really wonder what is the direction we are taking. I will not stop you with a veto, but I have the strong feeling these decisions are wrong. For the principle of not depending on contrib for our default user flavor, exchanging the blog app with the tour app, this does not make sens for me, sorry.

Thanks for reading.

On Wed, Jun 8, 2016 at 3:45 PM, Vincent Massol <[email protected]> wrote:

...

FTR I’ve discussed internally with Thomas, Marius and Anca and we all agreed that it makes sense to move The Tour app + CKEditor to the platform.

There are various reasons but a very important one is simply the manpower that it requires to maintain extensions on lots of XWiki versions and currently the active devs on xwiki are not enough to do that. This is the reason we dropped this strategy in the past and decided to release the whole platform together with the same version.

As part of this the technical debt is being increased since supporting several versions and old versions means doing hacks.

If you see another possibility that doesn’t require more work please raise it here.

We need to progress and have CKEditor and Tour bundled in 8.2M2(which is already started) and thus, barring any negative comments, we’ll start the move next week.

Thanks -Vincent

...

On 07 Jun 2016, at 15:39, Guillaume Delhumeau < [email protected]> wrote:

It also means to move the tour application in that old branches too.

2016-06-07 13:59 GMT+02:00 Vincent Massol <[email protected]>:

> >> On 07 Jun 2016, at 10:27, Vincent Massol <[email protected]> wrote: >> >> >>> On 07 Jun 2016, at 09:37, Guillaume Delhumeau < > [email protected]> wrote: >>> >>> Moving Tour Application into platform makes sense to me (it becomes a >>> critical component and deserves a proper support). >> >> For me, it’s really about the definition of what the XWiki github org > represents. Right now with the new strategy == “Everything needed for the > default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling > XE so far but that we’ll slim down a bit, for example by removing the Blog > app and move it to contrib). >> >> Now we could still decide to have some flavor in contrib and have the > tour app included in that flavor but not in “the default XWiki runtime”. In > practice this would mean promoting this flavor instead of the base/default > flavor. The question will arise anyway when we next talk about other > flavors that we may want to have in contrib such a KB flavor, workgroup > flavor, web flavor, etc. >> >>> However, the current >>> application supports XWiki >= 6.4.1. By moving it to platform, we will > only >>> support the last XWiki version. >> >> This is a tough topic indeed. > > Actually in practice we would support not only the last XWiki version but > also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we could (we > still have a stable-6.4.x branch ATM that we were supposed to remove) but > it would mean changing our support strategy to support more branches… and > it means supporting the whole platform for 6.4.x, not just one extension… > > Thanks > -Vincent > > >> For the tour there’s the solution of keeping it in contrib and > introducing a flavor but for CKEditor it’s harder to justify that it’s not > part of the base flavor IMO but maybe it’s possible and we would offer only > the wiki editor in the base flavor. Of course we could modify our > functional tests fwk to support running on various versions of the > dependencies and have CI builds to ensure that an extension works with all > versions but it’s not perfect and it would mean that for the first time we > would have code in the xwiki github org that would not use the latest > APIs/latest JDK features. >> >> The other option is Marius’s, i.e. accept that we hand-pick some > extensions from contrib that we bundle in the base/default flavor such as > the Tour app, CKEditor integration, etc. In this case, we would just need > to redefine what “xwiki github org” means. Saying “core component” would > not be enough, it would needs a more precise definition. >> >> Interesting topic ;) >> >> Any other option that we have? >> >> Thanks >> -Vincent >> >>> 2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>: >>> >>>> >>>>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < >>>> [email protected]> wrote: >>>>> >>>>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol <[email protected]> >>>> wrote: >>>>> >>>>>> >>>>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < >>>>>> [email protected]> wrote: >>>>>>> >>>>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hello all, >>>>>>>> >>>>>>>> As it was decided already, a Homepage Tour have to be implemented. >>>>>> However, >>>>>>>> no option regarding the place where the Tour Application should be >>>>>> added as >>>>>>>> dependency was discussed. >>>>>>>> >>>>>>>> There are some possible options: >>>>>>>> 1) XWiki Enterprise >>>>>>>> 2) XWiki Platform Distribution >>>>>>>> 3) XWiki Platform Helper >>>>>>>> >>>>>>>> 4) Is there any option to have the Tour Application as a part of > the >>>>>> Core ? >>>>>>>> >>>>>>>> What would be the best way to include the Contrib applications in >>>> XWiki? >>>>>>>> >>>>>>> >>>>>>> On this topic (sorry if I hijack your thread) I was wondering why > don't >>>>>> we >>>>>>> have dependencies from platform/enterprise to contrib. We have lots > of >>>>>>> third party dependencies, contrib could be considered as such. >>>> Moreover, >>>>>>> we're in the process of moving non-core (vertical) extensions out of >>>>>>> platform to contrib. It would be a pity to move something from > contrib >>>> to >>>>>>> platform and then back to contrib. I have the same issue with the >>>>>> CKEditor >>>>>>> Integration extension. We want CKEditor as the default editor, > bundled >>>>>> with >>>>>>> the default distribution, but do we need to move it to platform? > Same >>>> for >>>>>>> the Welcome Tour. >>>>>> >>>>>> I’d personally not like this for the following reasons: >>>>>> >>>>>> >>>>> >>>>>> 1) I like that the XWiki runtime is all released at once with all >>>>>> extensions making it using the same versions and verified to work >>>> together. >>>>>> >>>>> >>>>> XWiki runtime has lots of third party dependencies. Bootstrap, Solr, >>>>> jQuery, just to name a few. I don't see how having the source code in > our >>>>> repo (platform) makes a difference at runtime when the >>>>> integration/functional tests verify they work together. >>>> >>>> Because they don’t! :) Just check any extension in contrib and you’ll > see >>>> their func test (when they have some!) don’t test that they work with > the >>>> latest version of XWiki… >>>> >>>>> 2) Support. The XWiki runtime is supported by the XWiki Core Dev Team. >>>>>> Extensions in contrib are not supported by the XWiki Core Dev Team. >>>>> >>>>> >>>>> So the FAQ application you moved out of platform is no longer > supported >>>> by >>>>> the XWiki Core Dev Team? >>>> >>>> Correct. >>>> >>>>> The extension page >>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application >>>>> doesn't reflect this. >>>> >>>> I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” >>>> because it's a past authors and it wouldn’t make sense to remove it. > But >>>> yes it’s no longer officially supported by the XWiki Core Dev Team. >>>> >>>> Note that e.x.o doesn’t say who maintains a given extension, it just > says >>>> who participated to developing it ;) We’re currently missing the info > on >>>> whether the extension is actively supported and by whom. FTR Confluence >>>> does this with a “supported” label that you can hover over and provides >>>> info. For example: >>>> > https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number... >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> In addition xwiki-contrib is very open and anyone can make > modifications >>>>>> there and quality is thus harder to guarantee. >>>>>> >>>>>> We defined the xwiki github organization as containing horizontal >>>> modules, >>>>>> ie modules that can be required for any flavor and both CKEditor and > the >>>>>> Tour Application fit the need. By opposition to vertical modules > which >>>> make >>>>>> sense only for some use cases (like the Meeting Manager app) and not > by >>>>>> default in XE. We have the option of having flavors in contrib for >>>> those if >>>>>> we want though. For CKEditor it’s not a good thing since we’d like > it by >>>>>> default. >>>>>> >>>>>> One alternative (which I’m not fond of at all) would be to have > ckeditor >>>>>> as a separate git repo in the xwiki github organization. >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> Thanks, >>>>>>> Marius >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alex

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

Hi, On Mon, Jun 20, 2016 at 10:41 AM, Vincent Massol <[email protected]> wrote:

Since my last proposal didn’t get a consensus, let’s restart the discussion in more general terms:

Current Strategy =============

We defined it in the "xwiki core” thread (source: http://markmail.org/message/w6veilqhhnjqcw3e):

" 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, 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 "

Right now the goal of the XWiki Platform is to provide the **most usable generic runtime possible**.

According to this definition the Tour and CKEditor are both clearly platform modules.

Note that the goal of flavors right now is to provide verticals. It’s not to provide additional extensions that make the generic XWiki runtime more usable.

Future Options ============

There are only 2 options that are different from the current one and that I can imagine:

A) Keep the Tour application and CKEditor extension outside of XWiki Platform. The consequence is that the current strategy doesn’t apply anymore and we would need a new definition of XWiki Platform. One that I could see would be “a minimally usable generic runtime”, which is very undefined. For example, is the Annotation feature part of a minimal distribution. Answer: no. Actually we could even question if the EM is needed for a minimally usable runtime (first versions of XWiki were usable and didn’t have the EM). Activity Stream? AppWithinMinutes? Chart feature? So we would need to define clearly what we call a minimally usable runtime.

B) Move the Tour application and CKEditor extension inside XWiki Platform but start having different version/release lifecycle for some extensions. If we do this for the Tour or CK then there’s no reason not to do it for other extensions and very quickly we go back to what we were doing 6-8 years ago where it was a major PITA to do any release and to validate what extension version was working with what other extension.

I must say that I do find option B) interesting, not for moving CK/Tour inside platform, but for making more of the platform modules have independent release cycles. Probably almost all, except maybe for EM, or something like that, which would reach a point where it can not replace itself at runtime. Basically I have a big personal (?) problem in accepting the notion of "core" extensions that we currently have in XWiki. Sure, some extensions are "core" because of technical limitations that we currently have, but IMO we should work our way towards having almost no XWiki related jar inside the lib folder, and thus, having almost no core extensions that users are unable to upgrade or uninstall. Yes, I do realise this means Dependency Hell, but why not go in all the way and have all the advantages? I`m sure we could work around the development issues it introduces. My 2 cents on this. Thanks, Eduard

For me B) is not a good option and neither if A) unless we find a way to clearly define it.

My worry for A) is that it’s easy to say that we want a minimal runtime and this would mean moving a LOT of modules outside of platform and into contrib, which would mean a lot more work to maintain/release them (each module would have its release cycle). Releasing platform would becomes simpler (less stuff to build) but release the default flavor (in contrib) would become a major pain. And also, who would do it since there’s no notion of Release Manager for contrib. Any dev of contrib could release a new version of the default flavor and thus change what the default XWiki runtime is. I feel we need to control what the default XWiki runtime is and that should be the XWiki Core Dev Team who does this.

So at this point I believe that we need to keep the default flavor in platform and I don’t see any viable option other than the current strategy.

@Denis: if you’re in favor of A) please let us know how you’d implement it in detail and how you’d answer the challenges I raised.

Thanks -Vincent

...

On 09 Jun 2016, at 11:01, Vincent Massol <[email protected]> wrote:

Hi everyone,

Thanks for the replies. I’m listening of course to everyone and I’ve tried in this mail to take all answers into account.

First, let me state our current strategy and an alternative that I’ve been thinking about this morning under my shower ;)

Current Voted Strategy ==================

* Deliver an XWiki Runtime that is the best possible generic runtime (i.e. most usable, most useful). * As a consequence, remove all modules that vertical modules (i.e. that are clearly not useful to all flavors), such as FAQ, Blog, etc. Move them to xwiki-contrib * I want to stress out that the current voted strategy is not to produce a minimalist runtime

New Strategy Proposal ==================

I’ve tried to reconcile all the use cases listed in this thread before and I hope this proposal could be a good middle ground. In any case I found it worth debating to see if it could work.

Also note that one aspect that we must not forget (and that led to the last proposal I sent on this thread) and that people tend to forget, is the time it takes to support various versions of XE in an extension and the manpower that exists in the xwiki community (don’t forget that everything we do is a tradeoff; if you support another version of XE in an extension, it means you’re not coding an important improvement or fixing an important bug in the platform).

So here’s the idea:

* Change the purpose of the XWiki Github organization from the voted one described above to be: Provide a minimalist runtime. * Since working in this direction will not happen overnight, the idea would be to very slowly take out modules, starting with obvious ones. * The issue that this strategy raises is that users will not get a good user experience since lots of things will be lacking and this is where my new idea fills the gap: ** The first time (or whenever you upgrade) your run the XWiki Runtime (be it whether your run the HSQLDB/Jetty packaging or any other packaging) you get a Configuration wizard ** This Configuration Wizard suggest some recommended extensions that the XWiki Core Dev Team hand-pick. We would start with 2: *** Propose to the user to run a Tour to learn how to use XWiki (it would install the Home Page Tour which depends on the Tour app) *** Propose to the user to install the CKEDitor WYSIWYG editor (by default we would only propose the wiki editor - We’ll need to get rid of the GWT editor, probably make it an extension)

Pros: * The XWiki Core Dev Team continues to work on core stuff and as time progresses we move out non core stuff * This allows more people to contribute to the non-core stuff in the community * We control which extensions we want to recommend and thus we can always only take the very good ones and thus control the quality of the initial user experience * We get a mechanism allowing our users to get non-xwiki core dev team-supported extensions into the runtime (thus providing a good user experience) while not bundling them into the default XWiki runtime flavor.

Cons: * The Tour and CKeditor extensions would still incur a higher cost of support/maintenance (but since they’ve already done the code, it’s marginal for the future and they’ll be able to abandon support for XWiki 6.x soon IMO too - Basically they probably only need to support 2 or 2.5 cycle versions).

<similar idea> Ludo mentioned (and I agree with him) that it would be nice to be able to provide Demo content in the wiki so that users who want to test drive XWiki can do so with existing content and more clearly see and understand the advantages that XWiki brings. For this, I’d propose to create a Demo Content extension (some AWM app + some blog posts + etc) and once we have it, recommend it on the Configuration Wizard. </similar idea>

WDYT?

Thanks -Vincent

...

On 08 Jun 2016, at 17:57, Denis Gervalle <[email protected]> wrote:

Well, very sorry to drop in so late in this discussion, but it was not obvious from the thread subject that your were discussing a major subject.

IMO, moving application that works currently on 6.x to the core, has no benefit for our users, it just introduce restrictions. It does not have any benefit for us either, it just require more backports. I do not understand this move at all for application that are not minimal requirements. I do not understand your point Vincent when you say that these applications are horizontal and obviously part of platform according to your "Executive summary".

Regarding the tour application, it is not require at all, it is just a nice helping tool that we want to ease newcomers, but experienced user will never need it. It could be exchanged for an alternative, and it is exactly the same kind of application than the blog that we are moving out. Regarding the CKEditor, do we consider that a WYSIWYG editor is required for a wiki to be a wiki ? IMO, WYSIWYG editor is not a requirement to use the platform, it is nice to have, but not required. I have use it very sparsely until now, and not having it would not have change much for me.

So, I currently do not see any benefit of moving these modules to platform, since these are already well living in contrib.

Your other point about reducing platform to the minimal runtime would cause platform to reduce to EM does not really looks like something that will happen. In theory, you are right, so XWiki would be even less featured then maven. But, I doubt you could reasonably use such a tools for anything useful. I doubt XWiki compare to maven. I doubt that horizontal module like security, logging, model, storage, etc… will ever be considered optional. Even a plain text editor is a minimal requirement to starts, else this is no more a wiki, and I even wonder what it is ? a tool that brings together arbitrary java module… looks weird. So no, the minimal runtime is definitely not just EM.

So, I really wonder what is the direction we are taking. I will not stop you with a veto, but I have the strong feeling these decisions are wrong. For the principle of not depending on contrib for our default user flavor, exchanging the blog app with the tour app, this does not make sens for me, sorry.

Thanks for reading.

On Wed, Jun 8, 2016 at 3:45 PM, Vincent Massol <[email protected]> wrote:

...

FTR I’ve discussed internally with Thomas, Marius and Anca and we all agreed that it makes sense to move The Tour app + CKEditor to the platform.

There are various reasons but a very important one is simply the manpower that it requires to maintain extensions on lots of XWiki versions and currently the active devs on xwiki are not enough to do that. This is the reason we dropped this strategy in the past and decided to release the whole platform together with the same version.

As part of this the technical debt is being increased since supporting several versions and old versions means doing hacks.

If you see another possibility that doesn’t require more work please raise it here.

We need to progress and have CKEditor and Tour bundled in 8.2M2(which is already started) and thus, barring any negative comments, we’ll start the move next week.

Thanks -Vincent

...

On 07 Jun 2016, at 15:39, Guillaume Delhumeau < [email protected]> wrote:

It also means to move the tour application in that old branches too.

2016-06-07 13:59 GMT+02:00 Vincent Massol <[email protected]>:

...

> On 07 Jun 2016, at 10:27, Vincent Massol <[email protected]>

wrote:

...

> > >> On 07 Jun 2016, at 09:37, Guillaume Delhumeau < [email protected]> wrote: >> >> Moving Tour Application into platform makes sense to me (it becomes a >> critical component and deserves a proper support). > > For me, it’s really about the definition of what the XWiki github org represents. Right now with the new strategy == “Everything needed for the default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling XE so far but that we’ll slim down a bit, for example by removing the Blog app and move it to contrib). > > Now we could still decide to have some flavor in contrib and have the tour app included in that flavor but not in “the default XWiki runtime”. In practice this would mean promoting this flavor instead of the base/default flavor. The question will arise anyway when we next talk about other flavors that we may want to have in contrib such a KB flavor, workgroup flavor, web flavor, etc. > >> However, the current >> application supports XWiki >= 6.4.1. By moving it to platform, we will only >> support the last XWiki version. > > This is a tough topic indeed.

Actually in practice we would support not only the last XWiki version but also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we could (we still have a stable-6.4.x branch ATM that we were supposed to remove) but it would mean changing our support strategy to support more branches… and it means supporting the whole platform for 6.4.x, not just one extension…

Thanks -Vincent

> For the tour there’s the solution of keeping it in contrib and introducing a flavor but for CKEditor it’s harder to justify that it’s not part of the base flavor IMO but maybe it’s possible and we would offer only the wiki editor in the base flavor. Of course we could modify our functional tests fwk to support running on various versions of the dependencies and have CI builds to ensure that an extension works with all versions but it’s not perfect and it would mean that for the first time we would have code in the xwiki github org that would not use the latest APIs/latest JDK features. > > The other option is Marius’s, i.e. accept that we hand-pick some extensions from contrib that we bundle in the base/default flavor such as the Tour app, CKEditor integration, etc. In this case, we would just need to redefine what “xwiki github org” means. Saying “core component” would not be enough, it would needs a more precise definition. > > Interesting topic ;) > > Any other option that we have? > > Thanks > -Vincent > >> 2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>: >> >>> >>>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < >>> [email protected]> wrote: >>>> >>>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol < [email protected]> >>> wrote: >>>> >>>>> >>>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < >>>>> [email protected]> wrote: >>>>>> >>>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> As it was decided already, a Homepage Tour have to be implemented. >>>>> However, >>>>>>> no option regarding the place where the Tour Application should be >>>>> added as >>>>>>> dependency was discussed. >>>>>>> >>>>>>> There are some possible options: >>>>>>> 1) XWiki Enterprise >>>>>>> 2) XWiki Platform Distribution >>>>>>> 3) XWiki Platform Helper >>>>>>> >>>>>>> 4) Is there any option to have the Tour Application as a part of the >>>>> Core ? >>>>>>> >>>>>>> What would be the best way to include the Contrib applications in >>> XWiki? >>>>>>> >>>>>> >>>>>> On this topic (sorry if I hijack your thread) I was wondering why don't >>>>> we >>>>>> have dependencies from platform/enterprise to contrib. We have lots of >>>>>> third party dependencies, contrib could be considered as such. >>> Moreover, >>>>>> we're in the process of moving non-core (vertical) extensions out of >>>>>> platform to contrib. It would be a pity to move something from contrib >>> to >>>>>> platform and then back to contrib. I have the same issue with the >>>>> CKEditor >>>>>> Integration extension. We want CKEditor as the default editor, bundled >>>>> with >>>>>> the default distribution, but do we need to move it to platform? Same >>> for >>>>>> the Welcome Tour. >>>>> >>>>> I’d personally not like this for the following reasons: >>>>> >>>>> >>>> >>>>> 1) I like that the XWiki runtime is all released at once with all >>>>> extensions making it using the same versions and verified to work >>> together. >>>>> >>>> >>>> XWiki runtime has lots of third party dependencies. Bootstrap, Solr, >>>> jQuery, just to name a few. I don't see how having the source code in our >>>> repo (platform) makes a difference at runtime when the >>>> integration/functional tests verify they work together. >>> >>> Because they don’t! :) Just check any extension in contrib and you’ll see >>> their func test (when they have some!) don’t test that they work with the >>> latest version of XWiki… >>> >>>> 2) Support. The XWiki runtime is supported by the XWiki Core Dev Team. >>>>> Extensions in contrib are not supported by the XWiki Core Dev Team. >>>> >>>> >>>> So the FAQ application you moved out of platform is no longer supported >>> by >>>> the XWiki Core Dev Team? >>> >>> Correct. >>> >>>> The extension page >>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application >>>> doesn't reflect this. >>> >>> I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” >>> because it's a past authors and it wouldn’t make sense to remove it. But >>> yes it’s no longer officially supported by the XWiki Core Dev Team. >>> >>> Note that e.x.o doesn’t say who maintains a given extension, it just says >>> who participated to developing it ;) We’re currently missing the info on >>> whether the extension is actively supported and by whom. FTR Confluence >>> does this with a “supported” label that you can hover over and provides >>> info. For example: >>>

https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.number...

...

...

...

>>> >>> Thanks >>> -Vincent >>> >>>> In addition xwiki-contrib is very open and anyone can make modifications >>>>> there and quality is thus harder to guarantee. >>>>> >>>>> We defined the xwiki github organization as containing horizontal >>> modules, >>>>> ie modules that can be required for any flavor and both CKEditor and the >>>>> Tour Application fit the need. By opposition to vertical modules which >>> make >>>>> sense only for some use cases (like the Meeting Manager app) and not by >>>>> default in XE. We have the option of having flavors in contrib for >>> those if >>>>> we want though. For CKEditor it’s not a good thing since we’d like it by >>>>> default. >>>>> >>>>> One alternative (which I’m not fond of at all) would be to have ckeditor >>>>> as a separate git repo in the xwiki github organization. >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>>> Thanks, >>>>>> Marius >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Alex

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Mon, Jun 6, 2016 at 3:50 PM, Vincent Massol <[email protected]> wrote:

...

On 06 Jun 2016, at 14:09, Alexandru Cotiuga <[email protected]> wrote:

Hello all,

As it was decided already, a Homepage Tour have to be implemented. However, no option regarding the place where the Tour Application should be added as dependency was discussed.

There are some possible options: 1) XWiki Enterprise 2) XWiki Platform Distribution 3) XWiki Platform Helper

4) Is there any option to have the Tour Application as a part of the Core ?

What would be the best way to include the Contrib applications in XWiki?

Yes, if we want to have the tour on XE by default ,we need to VOTE to move the Tour app in xwiki-platform first (that would be a VOTE mail that you need to send).

The alternative is to create a flavor of XWiki in xwiki-contrib and make it the default flavor on the download page (and keep the XWiki base flavor from platform as some technical flavor that should not be used by end users).

My preference goes to having the tour app in platform.

Is the tour application a core extension? I thought we were moving non-core (vertical) extensions out of platform. Why can't we have dependencies from platform to contrib?

Thanks -Vincent

...

Thanks, Alex

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs