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 <vincent@massol.net> 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 < guillaume.delhumeau@xwiki.com> wrote:
It also means to move the tour application in that old branches too.
2016-06-07 13:59 GMT+02:00 Vincent Massol <vincent@massol.net>:
On 07 Jun 2016, at 10:27, Vincent Massol <vincent@massol.net> wrote:
On 07 Jun 2016, at 09:37, Guillaume Delhumeau < guillaume.delhumeau@xwiki.com> 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 <vincent@massol.net>:
> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote: > > On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol <vincent@massol.net> wrote: > >> >>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < >> mariusdumitru.florea@xwiki.com> wrote: >>> >>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >>> alexandru.cotiuga@xwiki.com> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau (guillaume.delhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau (guillaume.delhumeau@xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO