> On 07 Jun 2016, at 11:36, Ecaterina Moraru (Valica) <[email protected]> wrote: > > So the main concerns are: > A. moving (changing history, ids, versioning scheme, version compatibility, > etc.) > B. commit rights & ownership > C. support definition
What’s more important for me is D: what we want the xwiki github org to be (see my other mails before and after on this thread). Thanks -Vincent > A. Maybe in the future we might want to create flavors that contain > community applications, without the need to move them somewhere (like Mocca > Calendar for example). > I don't like moving things around, losing history, breaking ids, > versioning, etc. > It is an interesting topic because in the past years, when we experimented > something, we first committed code outside of platform. So the move topic > will happen for other apps too. > > B. Regarding commit rights, they can be set per repository. So we could > indeed handpick apps and allow only committers to support them. Now this > indeed implies changing some of our definitions and providing such a list > of applications. > Regarding ownership, I think preserving the initial owner of the app, gives > the appropriate credits to him. From a community perspective I think is > better for an app to be attribute to the initial committer, rather than > switching the ownership to XWiki's Development Team. > > C. Now the problem is the 'support', since as you said it's hard for as > committers to offer support for apps that are not in platform. Changing the > commit rights from contrib to committers could be a solution, if the owner > agrees. Now IMO we can easily change the definition of what 'support' > means, we only need motivation and to see additional benefits. > > So I would: > - ask the owner if he wants his app to be bundled by default > - not move the app, just use as a dependency > - ask if we can change the initial rights to allow committers + owner(s), > instead of contrib. A note that for some apps, multiple people could be > better suited to 'support' the app, rather than the committers group > - ask the owner if he can 'support' the app. Bundling an app implies that > the committers will support it, but additional owners can and should > support it. If the owners would like to support the app, but they are not > committers, I would not want us to be 'forced' to give commit rights just > because we will need to move the app inside platform. Or for the owner to > 'renounce' his app. > - as part of the support agreement, request the app to have functional > tests and have a job on ci. > > So the other problems remaining are different version schemes, > compatibility and the list of bundled contrib apps: > - Compatibility will be better since you could install new versions of the > app, on older versions of XE. Now the testing will be more problematic (in > mixing different version). > - Compatibility field on e.x.o needs to be updated on every XE release. > This could mean increased work for the RM or the owner(s). > - The list of bundled apps can be generated using the 'bundled' property we > have on Repository app. > > Anyway :) this implies some changes. I would like us not to move the app, > but not sure how this will fully impact our current rules. > > Thanks, > Caty > > > On Tue, Jun 7, 2016 at 11:27 AM, 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. 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
