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

Sounds good enough. On Mon, Jun 20, 2016 at 12:48 PM, Vincent Massol <vincent(a)massol.net> wrote: 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. part of xwiki-platform (this would be xwiki-platform-distribution). 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. 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). 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. (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. discussion in more general terms: http://markmail.org/message/w6veilqhhnjqcw3e): organization by only keeping “core” modules (i.e. that can be used in lots of XWiki flavors, if not all). This is opposed to “vertical” distribution wizard, annotations, active installs, one base flavor (the “XWiki application, FAQ application, flavors (except the base flavor), etc usable generic runtime possible**. platform modules. not to provide additional extensions that make the generic XWiki runtime more usable. that I can imagine: 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. 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. to clearly define it. 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. platform and I don’t see any viable option other than the current strategy. it in detail and how you’d answer the challenges I raised. tried in this mail to take all answers into account. been thinking about this morning under my shower ;) (i.e. most usable, most useful). that are clearly not useful to all flavors), such as FAQ, Blog, etc. Move them to xwiki-contrib produce a minimalist runtime 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. 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). one described above to be: Provide a minimalist runtime. would be to very slowly take out modules, starting with obvious ones. good user experience since lots of things will be lacking and this is where my new idea fills the gap: (be it whether your run the HSQLDB/Jetty packaging or any other packaging) you get a Configuration wizard the XWiki Core Dev Team hand-pick. We would start with 2: would install the Home Page Tour which depends on the Tour app) default we would only propose the wiki editor - We’ll need to get rid of the GWT editor, probably make it an extension) progresses we move out non core stuff community always only take the very good ones and thus control the quality of the initial user experience team-supported extensions into the runtime (thus providing a good user experience) while not bundling them into the default XWiki runtime flavor. 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). 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. subject. no have any understand do applications are a nice exactly required use me. platform, cause will featured then module like optional. this is together stop wrong. flavor, for me, wrote: platform. manpower is the the supporting raise 8.2M2(which is start the wrote: becomes a org for the the other workgroup we will version could remove) branches… it’s offer with time latest such just would vincent(a)massol.net> should part of applications in wondering why have such. extensions out from with the editor, platform? all work Solr, code you’ll work with Dev Team. remove it. Team. just the info https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.numbe… horizontal CKEditor modules and contrib for like have -- Thomas Mortagne _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs