> On 23 Jun 2016, at 09:11, Vincent Massol <[email protected]> wrote: > >> >> On 22 Jun 2016, at 20:13, Eduard Moraru <[email protected]> wrote: >> >> Hi, >> >> On Wed, Jun 22, 2016 at 12:57 PM, Vincent Massol <[email protected]> wrote: >> >>> >>>> On 22 Jun 2016, at 10:02, Marius Dumitru Florea < >>> [email protected]> wrote: >>>> >>>> +1 >>>> >>>> On Tue, Jun 21, 2016 at 7:00 PM, Vincent Massol <[email protected]> >>> wrote: >>>> >>>>> Hi devs, >>>>> >>>>> I’m transforming the brainstorming that was started in the thread >>>>> http://markmail.org/message/exlndbq3tw2thmmu into a VOTE mail since >>> this >>>>> is a very important decision. >>>>> >>>>> So I’m asking you to vote for defining a new direction for the XWiki >>> Core >>>>> Dev Team (i.e. for the XWiki GitHub Organization). The need was >>> triggered >>>>> by the Tour and CKEditor extensions which are currently in xwiki-contrib >>>>> and that we want our users to have by default. For more details see this >>>>> thread: http://markmail.org/message/exlndbq3tw2thmmu >>>>> >>>>> So here’s the strategy: >>>>> >>>>> * 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). >>>>> >>>> >>>> I don't think we need to release the Default Flavor more often than the >>>> Base Flavor because with this new strategy the users can upgrade >>> individual >>>> extensions (those that are not in the Base Flavor) without upgrading the >>>> WAR. >>> >>> As I said, if we find some important bug (for example) and this bug is >>> only in one of the 3rd party extensions, it would be a pity not to release >>> just the Default Flavor IMO and wait for 2 months more. Even if users can >>> upgrade their extensions, it’s better that users new to XWiki >>> download/install the best possible version right away instead of having to >>> upgrade. >>> >>> We’ll see when the need arises but I don’t think we should stop ourselves >>> from this possibility. Technically this means putting the Default Flavor in >>> a separate github repo (same as xwiki-enterprise being in a separate repo). >>> We need to discuss how we do it: >>> - consider it’s XE for now and just add the 2 deps of Tour and CK to XE >>> - introduce a new repo for the default flavor and do the build for it and >>> deprecate XE in favor of it. For now we probably need to hardcode the >>> flavor id in the platform WAR till we’re ready to have the flavor selection >>> screen at startup (and for HSQLDB/Jetty packaging we need a hard-coded >>> flavor anyway). >>> >> >> I`m personally sensing that we may have a bit of a confusion here between >> the notion of separate release cycles and the repo in which an extension >> should be located. >> >> AFAIU, the top priority and the actual problem that we want to fix here >> (mainly for our users and XWIki`s flexibility) is to allow extensions to >> have independent release cycles. Moving stuff to contrib just got somehow >> into the discussion as a consequence of the old way we used to handled >> things (xwiki org = monolith, single version; contrib org = distributed; >> independent versions). >> >> In the past, people (including myself) were pushing to move modules to >> contrib for the independent versioning feature of contrib, but not >> necessarily for the "openness for anyone to commit" feature of contrib. >> That last feature was actually a downside to the quality aspect. If we >> handle independent versioning within the xwiki GitHub organization, then we >> will no longer have this downside and we will be able to properly control >> the quality. This would mean that the Default Flavor would be in a repo >> under the xwiki org (similar to xwiki-enterprise, as Vincent's proposal) >> and I would even go as far as suggesting that all the dependencies of the >> Default Flavor should be located/moved within the xwiki org, perhaps in >> some xwiki-extensions repo (that we were talking about at some point). >> >> I agree that this might sound a bit like going in circles, but IMO it`s not >> entirely true, now that we introduce independent versioning in the >> discussion, since it fixes a lot of problems we have in the previous >> discussions were we were wrongly using Contrib, to compensate for it, since >> the xwiki org was a big monolith. >> >> Now what happens to the remaining modules inside xwiki-platform and the >> Base Flavor, I would guess that, at least at the beginning, they will >> continue to function as a monolith, at least until we decide to tackle the >> notion of "core" dependencies and if we want to do something about them >> (see my note about this on the previous thread). >> >> WDYT? > > Indeed going in circles a bit here but it’s an important decision… However we > need to conclude quickly since we need to implement the solution for 8.2RC1 > i.e. we need to close this thread at latest this week. > > Point 1: Scope of xwiki github org > ========================== > > The strategy we’re voting here is about having XWiki Core Dev Team (aka XWiki > Github Org) to be focusing about core stuff and reducing the scope of the > core as we progress. And letting the community at large handle the non-core > modules. > > What you mention above (and which was already proposed in the previous thread > BTW) would lead to keep the same scope for the XWiki Core Dev Team. > > As you mention it also leads to making it more complex for others to > contribute. > > Also don’t forget that we’ve already voted to move stuff ouf of xwiki github > org and we’ve already started (markdown syntax, various platform modules > already moved out), and have even already voted to move more stuff out. > > So the direction is to slim down the xwiki github repo, not just because we > also want users to be able to install extensions in older versions of XWiki. > > Point 2: dependency hell > =================== > > I would prefer that we keep releasing all XWiki Github Org together as much > as possible to avoid dep hell (and increased testing efforts) as we had > before. It’s fine to decide to include a few third party modules but that’s > very different from deciding that the rule is now that all modules can have > their own release cycle inside core. > > If the way to do this and be consistent is to say that the default flavor is > released with the same versioning cycle than all the rest of the XWiki Github > Org then I’d prefer that. > > Other thoughts > ============ > > Now we could decide to move just CKEditor inside xwiki github org with the > argument of controlling the quality. I think it would be more difficult to > justify moving the Tour app. Also note that we should prevent ourselves from > being able to bundle other third party extensions in the future in the > default flavor if we think they should be in by default so I think we should > still keep the strategy proposed in this thread.
^^^^^ Also note that we should NOT prevent ourselves from being able to bundle other third party extensions in the future... Thanks -Vincent > > I view the proposal in this mail as an add-on and not a replacement, i.e. to > be clear: > * Keep the same logic as proposed for xwiki github org > * Still have a base and default flavor in xwiki github org > * Still be allowed to bundle third party extensions in the default flavor > * NEW: Allow ourselves to have special extensions in xwiki github org that > have their own release cycles, and CK would be the first > > Right now I’m not fully convinced that we need to do this and I’d rather > continue with the proposal as is and keep CK outside. The only reason to move > it to the xwiki github org IMO is for quality reasons and I’d rather wait > till we see a problem before considering it. > > Actually this thread mentioned about defining what a “basic wiki” is. I think > we should consider moving CK in only if we consider that a WYSIWYG editor is > part of a “basic wiki”. But I’m not convinced that a basic wiki requires 2 > editors (the wiki one + a WYSIWYG one). > > WDYT? > > Thanks > -Vincent > >> Thanks, >> Eduard >> >> So, having that in mind, I would think of some questions: >> - >> >>> >>> Thanks >>> -Vincent >>> >>>> Currently the users cannot upgrade the Blog because the new version of >>>> the Blog depends on a new version of the XWiki WAR. With this new >>> strategy >>>> the users will be able to upgrade the Blog (considering that the Blog is >>>> not part of the Base Flavor). >>>> >>>> On the same topic, we have the Extension Updater administration section >>>> where users can check for extension updates. The problem is that the >>>> extensions included in a flavor are considered dependencies of the flavor >>>> and thus are installed as dependencies which means the Extension Updater >>>> cannot separate them from other technical dependencies and thus won't >>> check >>>> for their updates. Ideally a flavor should be a pack of extensions that >>> are >>>> installed explicitly (not as dependencies). This way the Extension >>> Updater >>>> can propose updates and at the same time the users can uninstall >>> extensions >>>> from a flavor without removing the flavor. >>>> >>>> Thanks, >>>> Marius >>>> >>>> >>>>> * 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. >>>>> >>>>> Here’s my +1 >>>>> >>>>> Please cast your vote. >>>>> >>>>> Thanks >>>>> -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
