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.numberedheadings/cloud/overview > >>>>>>> > >>>>>>> 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
