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 <[email protected]> wrote: > > > On 09 Jun 2016, at 11:15, Ecaterina Moraru (Valica) <[email protected]> > wrote: > > > > 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 <[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 > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
