21 Jun
2016
21 Jun
'16
11:33 p.m.
Hi,
On Mon, Jun 20, 2016 at 10:41 AM, Vincent Massol <vincent(a)massol.net> 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
<vincent(a)massol.net> 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 <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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs