9 Jun
2016
9 Jun
'16
2:43 a.m.
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 <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:
workgroup
could
of
out
you’ll
Team.
it.
https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.numbe…
for
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
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
a
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
>>> 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, >> 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 (we
time
> 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 we
would
> 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” >> 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 >> 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 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
>> 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
>>>>>
>>>>>
>>>>> 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
>> 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:
>>>>
>
>>>>
>>>> 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 >>>>> 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
>>>
>>
>>
>>
>> --
>> Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
>> Research & Development Engineer at XWiki SAS
>> Committer on the XWiki.org project
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs