> On 23 Jun 2016, at 09:26, Denis Gervalle <[email protected]> wrote: > > Hi, > > On Wed, Jun 22, 2016 at 8:13 PM, 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). >> > > While I agree with your reasoning about why we like the move to contrib for > extensions, if you remember well our discussion about the repositories, the > reason that we have somehow abandoned the idea of a xwiki-extension repo > was mainly to avoid moving sources from one repository to another. > > I am still convinced that the drawback of moving sources is worse than the > risk of seeing very bad quality code being committed to a contrib > extension. Just look at the CKEditor one which live in contrib since a > while, does it receive any bad contribution (or even an external > contribution at all) ? I doubt, and if anything bad happen, I am > convinced Marius will notice and react. So I am not sure your fears are > justified at the moment. > > If our community were growing more, and the quality of some extensions > start to be an issue, it will still be the time to move them to a safer > place, or to strengthen the access right on contrib repositories. But I > would like to trust the community to be responsible, and that this time > will never happen. I would like to hope for the best, which would be that > our community will grow thanks to how easier it will be to participate, and > that good developers will join and help improve the overall quality. Let’s > us not under estimate how responsible the OS community could be.
<fun, please don’t consider it seriously> I agree with this but just for the fun of it (cannot resist, sorry ;)): If you push this reasoning you could also consider moving everything from the xwiki github org into the xwiki-contrib org... But wait, this is the same as actually moving everything from contrib to the xwiki github org too and relaxing committership rules :) </fun, please don’t consider it seriously> Thanks -Vincent > Thanks, > > >> >> 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? >> >> 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
