Sounds good enough. On Mon, Jun 20, 2016 at 12:48 PM, Vincent Massol <[email protected]> wrote: > Ok so I’ve brainstormed with Denis and we worked on option A) below. > > Here’s what we could do: > > * Make XWiki Github org == minimal runtime, where minimal means “basic wiki” > (page edition, history, linking, wiki markup, etc). The notion of “basic > wiki” would need to be better defined but this can be done later on. > * Provide a "Base Flavor" which corresponds to this “basic wiki”, as part of > xwiki-platform (this would be xwiki-platform-distribution). > * Provide another flavor, the "Default Flavor” which would add some > hand-picked third-party extensions (i.e. from contrib) such as the Tour app > and CKEditor (to start with, we could also add the markdown syntax for > example which is one of the most asked syntaxes). Note that this Default > Flavor would actually be a “replacement" of xwiki-enterprise. > * The Default Flavor would have at least the same release cycle as the base > flavor but it could have more releases (if some of the bundled third-party > extensions has some important bug fixes or new features that we want to offer > quickly without waiting for the next base flavor release). > * The consequence is that the XWiki Dev Team would need to be a bit more > careful to monitor the quality of bundled third-party extensions in contrib > (check commits, do some smoke testing, etc). Note that the goal of the > Default flavor would not be to offer verticals (for this there should be some > contrib flavors) and thus it wouldn’t bundle a lot of third-party extensions. > Basically we’ll need to validate the version of those third-party extensions > that include in the flavor. > > My POV is that globally this would offer more flexibility for our users > (they’ll be able to install extensions such as CK and Tour in older XWiki > versions and they’ll get more frequent releases) at the cost of some overhead > to develop extensions that work in several versions. The dev team is pretty > small and thus it means developing a bit less fast but it’s probably as > important, if not more important, to make the code we develop available in > older xwiki versions, as XWiki gains traction. > > WDYT? > > Thanks > -Vincent > > >> On 20 Jun 2016, at 09:41, Vincent Massol <[email protected]> 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. >> >> 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 <[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
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
