Hi, Denis, Indeed, moving things around back and forward from contrib and xwiki-extensions was probably the biggest con, while an acceptable pro for using just contrib was that we still control who is part of contrib. That way, if someone should abuse our trust, they will get kicked out.
So, to reiterate, I`m +1 with going forward by moving non-essentials to contrib and having the default flavor depend on contrib (individually versioned) stuff. I guess we will leave the discussion about individual versioning inside the xwiki github org for another time, since we`re already making a good step for the moment. Thanks, Eduard P.S.: About the Default Flavor, I`m not sure we really need to create a new repo instead of just reusing xwiki-enterprise and agreeing that it (already) *is* the default flavor, it just gets labelled properly and suffers this slight 3rd party extensions policy upgrade. On Thu, Jun 23, 2016 at 10:26 AM, 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. > > 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 > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Denis Gervalle > SOFTEC sa - CEO > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
