[xwiki-devs] [VOTE] New Strategy for the XWiki Github Organization
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). * 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
On Tue, Jun 21, 2016 at 6: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). * 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.
IMO, the overhead will depends on the needs, but what will be a net benefice is not to artificially raise extensions requirements when there is no change, or when the change does not implies the need for a recent API. +1, of course :)
Here’s my +1
Please cast your vote.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
+1 I like the fact that we don't move things around and that we support old versions of XWiki. We still need to clearly define what Base Flavor / Default Flavor include and how contrib users will create new Flavors on top of them. We still need to define the versioning scheme for the extensions that will go in the Default Flavor or in other possible future 'supported' contrib Flavors. (especially since you said they could have multiple releases) (maybe something like 8.2.1-x, although might be strange that you could install an 8.2.1-1 version of Tour in a 6.4 XWiki. Maybe we could use the year like 2016-1-1 or I don't know we need to think about it). And we need to see where we document what each Flavor contains and the procedure to add/remove extensions in the Flavors. Thanks, Caty On Tue, Jun 21, 2016 at 7:09 PM, Denis Gervalle <[email protected]> wrote:
On Tue, Jun 21, 2016 at 6: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). * 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.
IMO, the overhead will depends on the needs, but what will be a net benefice is not to artificially raise extensions requirements when there is no change, or when the change does not implies the need for a recent API.
+1, of course :)
Here’s my +1
Please cast your vote.
Thanks -Vincent
_______________________________________________ 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
+1 (not binding) On Tue, Jun 21, 2016 at 7:19 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
+1
I like the fact that we don't move things around and that we support old versions of XWiki.
We still need to clearly define what Base Flavor / Default Flavor include and how contrib users will create new Flavors on top of them. We still need to define the versioning scheme for the extensions that will go in the Default Flavor or in other possible future 'supported' contrib Flavors. (especially since you said they could have multiple releases) (maybe something like 8.2.1-x, although might be strange that you could install an 8.2.1-1 version of Tour in a 6.4 XWiki. Maybe we could use the year like 2016-1-1 or I don't know we need to think about it). And we need to see where we document what each Flavor contains and the procedure to add/remove extensions in the Flavors.
Thanks, Caty
On Tue, Jun 21, 2016 at 7:09 PM, Denis Gervalle <[email protected]> wrote:
On Tue, Jun 21, 2016 at 6: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). * 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.
IMO, the overhead will depends on the needs, but what will be a net benefice is not to artificially raise extensions requirements when there is no change, or when the change does not implies the need for a recent API.
+1, of course :)
Here’s my +1
Please cast your vote.
Thanks -Vincent
_______________________________________________ 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
Hi, +1. Even if it would imply a bit more work and management, I think it was unavoidable due to XWiki`s platform nature. My only note was about the mention on the previous thread that EM would/could not be considered part of the base flavor, in that I`m not sure I agree with that and, again, due to the platform nature of XWiki, EM should be considered core. We were even discussing in the past that the minimal distribution could be EM *alone*... so I can`t agree now with removing it. I know it was just an idea, just want to clarify it. Thanks, Eduard On Tue, Jun 21, 2016 at 7:54 PM, Alexandru Cotiuga < [email protected]> wrote:
+1 (not binding)
On Tue, Jun 21, 2016 at 7:19 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
+1
I like the fact that we don't move things around and that we support old versions of XWiki.
We still need to clearly define what Base Flavor / Default Flavor include and how contrib users will create new Flavors on top of them. We still need to define the versioning scheme for the extensions that will go in the Default Flavor or in other possible future 'supported' contrib Flavors. (especially since you said they could have multiple releases) (maybe something like 8.2.1-x, although might be strange that you could install an 8.2.1-1 version of Tour in a 6.4 XWiki. Maybe we could use the year like 2016-1-1 or I don't know we need to think about it). And we need to see where we document what each Flavor contains and the procedure to add/remove extensions in the Flavors.
Thanks, Caty
On Tue, Jun 21, 2016 at 7:09 PM, Denis Gervalle <[email protected]> wrote:
On Tue, Jun 21, 2016 at 6: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). * 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.
IMO, the overhead will depends on the needs, but what will be a net benefice is not to artificially raise extensions requirements when there is no change, or when the change does not implies the need for a recent API.
+1, of course :)
Here’s my +1
Please cast your vote.
Thanks -Vincent
_______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 21 Jun 2016, at 23:22, Eduard Moraru <[email protected]> wrote:
Hi,
+1. Even if it would imply a bit more work and management, I think it was unavoidable due to XWiki`s platform nature.
My only note was about the mention on the previous thread that EM would/could not be considered part of the base flavor, in that I`m not sure I agree with that and, again, due to the platform nature of XWiki, EM should be considered core.
EM is core for sure. That’s the way XWiki is built.
We were even discussing in the past that the minimal distribution could be EM *alone*... so I can`t agree now with removing it. I know it was just an idea, just want to clarify it.
Sure, I agree. I was clumsy in the previous thread, what I meant was that the ability to add extensions could be even be considered as not being a feature of a basic wiki (but would still be used underneath by us since we need it). But anyway, I completely agree about what we said in the past and what you said again here, that is that if we push it to the end, EM may even be what remains when all else has been externalized as extensions. Right now though, a good first step towards that direction (and that’s already challenging) is to give the direction that the Base Flavor be corresponding to a “basic wiki”. Once we reach that level we can then discuss about going further (or not). Thanks -Vincent
Thanks, Eduard
On Tue, Jun 21, 2016 at 7:54 PM, Alexandru Cotiuga < [email protected]> wrote:
+1 (not binding)
On Tue, Jun 21, 2016 at 7:19 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
+1
I like the fact that we don't move things around and that we support old versions of XWiki.
We still need to clearly define what Base Flavor / Default Flavor include and how contrib users will create new Flavors on top of them. We still need to define the versioning scheme for the extensions that will go in the Default Flavor or in other possible future 'supported' contrib Flavors. (especially since you said they could have multiple releases) (maybe something like 8.2.1-x, although might be strange that you could install an 8.2.1-1 version of Tour in a 6.4 XWiki. Maybe we could use the year like 2016-1-1 or I don't know we need to think about it). And we need to see where we document what each Flavor contains and the procedure to add/remove extensions in the Flavors.
Thanks, Caty
On Tue, Jun 21, 2016 at 7:09 PM, Denis Gervalle <[email protected]> wrote:
On Tue, Jun 21, 2016 at 6: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). * 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.
IMO, the overhead will depends on the needs, but what will be a net benefice is not to artificially raise extensions requirements when there is no change, or when the change does not implies the need for a recent API.
+1, of course :)
Here’s my +1
Please cast your vote.
Thanks -Vincent
+1 On Tue, Jun 21, 2016 at 6: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). * 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
-- Thomas Mortagne
+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. 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
+1 2016-06-22 10:02 GMT+02:00 Marius Dumitru Florea < [email protected]>:
+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. 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
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
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). 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
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? 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
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. 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
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
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
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
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
So the proposal for 8.2 (we’re already at RC1) is to consider that the default flavor is XE for now and to add the Home Page Tour + CKEditor extensions to XE. We can then decide later on 8.3+) how we transition from XE to the default flavor. Hope it’s fine with everyone. Thanks -Vincent
On 21 Jun 2016, at 18:00, 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). * 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
participants (8)
-
Alexandru Cotiuga -
Denis Gervalle -
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol