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
<dgl(a)softec.lu> 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 <vincent(a)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(a)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(a)massol.net>et>:
>>
>>>
>>>> On 07 Jun 2016, at 10:27, Vincent Massol <vincent(a)massol.net>
wrote:
>>>>
>>>>
>>>>> On 07 Jun 2016, at 09:37, Guillaume Delhumeau <
>>> guillaume.delhumeau(a)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(a)massol.net>et>:
>>>>>
>>>>>>
>>>>>>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea <
>>>>>> mariusdumitru.florea(a)xwiki.com> wrote:
>>>>>>>
>>>>>>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol
<vincent(a)massol.net>
>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea <
>>>>>>>> mariusdumitru.florea(a)xwiki.com> wrote:
>>>>>>>>>
>>>>>>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga
<
>>>>>>>>> alexandru.cotiuga(a)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.numbe…
>>>>>>
>>>>>> 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