I prefer this proposal too. 2016-06-20 15:10 GMT+02:00 Thomas Mortagne <[email protected]>:
> 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 > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
