Re: [xwiki-devs] Strategy for XWiki GitHub Organization (was Re: [Contrib] Tour Application dependency in XWiki)

On 09 Jun 2016, at 13:45, Eduard Moraru <enygma2002(a)gmail.com> wrote: Hi, As far as I can see, you want to make sure that the user installs the Tour,

for example, so that it is executed at the right time. However, why not let the flavor take care of this? Since the user will be choosing a flavor to install, it would also contain the tour (if it needs it) and everything will be set up.

For additional extensions that the admin wants to install, we have the EM UI and we can have recommended extensions displayed there. An extra step just for the recommended extensions is too much IMO and just gets in the way.

We still control what the standard flavor contains (tour, CK, etc.) and we still control what (contrib) extensions to recommend in the EM UI. IMO, that is enough.

Thanks, Eduard On Thu, Jun 9, 2016 at 2:12 PM, Ecaterina Moraru (Valica) &lt;valicac(a)gmail.com > I think that if we are to have Recommended extensions inside e.x.o and EM, > I would consider it a bit too much to have them also in DW. But maybe this > is another discussion. > > Thanks, > Caty > > On Thu, Jun 9, 2016 at 1:50 PM, Vincent Massol &lt;vincent(a)massol.net> >> >>> On 09 Jun 2016, at 11:15, Ecaterina Moraru (Valica) &lt;valicac(a)gmail.com >> >>>> >>> Hi, >>> >>> Where are the Flavors in this proposal? >> >> IMO Flavors don’t change; they’re still there and you still get them when >> you start with an empty wiki. When you start an empty wiki you pick the >> flavor you want and on the configuration screen, there are some > recommended >> extensions that are proposed. I think that’s the difference: flavors are > a >> fixed set of extensions. The Recommended extensions screen is just for >> optional stuff that you may want. If the recommended extensins are > brought >> as part of the flavor (ie if they are already installed) then they won’t > be >> suggested on the configuration screen. >> >> Basically flavors are distribution. Once you install a distribution you >> can still install additional extensions by going to the Extension > Manager. >> However we make the user’s file easier when he starts the first time by >> proposing some extensions. >> >> This provides 2 advantages: >> * We bring extensions that we deem important but that are not maintainted >> by the xwiki core dev team to the user. He doesn’t need to discover the > EM >> UI nor find out which extensions are super nice for me. >> * It allows to propose some extensions that need to run early in the >> process, such as the Tour (the user needs the Tour to know how to reach > the >> EM UI ;)). >> >> Another way of viewing this is that it’s a new feature of the EM/DW UI. >> The EM/DW module would provide a Recommended Extensions view as a Wizard >> when XWiki runtime starts the first time (and at each upgrade). Now what > we >> would need to be careful about is not drowning the user under 50 >> recommended extensions or it would loose its power. I think this config >> wizard view should focus on Extensions that are super useful for getting >> started. Then later one the user could go to the EM UI and get a full > list >> of Recommended Extensions, not just the one important for getting > started. >> >> WDYT? >> >> Thanks >> -Vincent >> >>> Thanks, >>> Caty >>> >>> On Thu, Jun 9, 2016 at 12:01 PM, Vincent Massol &lt;vincent(a)massol.net&gt; >>>> >>>> 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 &lt;dgl(a)softec.lu>>>>> >>>>> 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 &lt;vincent(a)massol.net&gt; >>>>>>>> >>>>>> 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>>>>>>> >>>>>>> It also means to move the tour application in that old branches > too. >>>>>>> >>>>>>> 2016-06-07 13:59 GMT+02:00 Vincent Massol &lt;vincent(a)massol.net&gt;et>: >>>>>>> >>>>>>>> >>>>>>>>> On 07 Jun 2016, at 10:27, Vincent Massol &lt;vincent(a)massol.net&gt; >>>>>>>>>> >>>>>>>>> >>>>>>>>>> On 07 Jun 2016, at 09:37, Guillaume Delhumeau < >>>>>>>> guillaume.delhumeau(a)xwiki.com>>>>>>>>>> >>>>>>>>>> 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 &lt;vincent(a)massol.net&gt;et>: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < >>>>>>>>>>> mariusdumitru.florea(a)xwiki.com>>>>>>>>>>>> >>>>>>>>>>>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol < >>>> vincent(a)massol.net&gt; >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < >>>>>>>>>>>>> mariusdumitru.florea(a)xwiki.com>>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >>>>>>>>>>>>>> alexandru.cotiuga(a)xwiki.com>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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