Re: [xwiki-devs] [Proposal] Move out Chart Macro + Renderer to Contrib
Hi, Let`s think about active installs. The client module (i.e. the one doing the work and reporting) can be considered core, but the server module (the one receiving and showing a UI of the collected data) is not really core and can be moved to contrib. This will also fix the chart macro issue, since it's the server/ui module depending on it and not the client-api one. Thanks, Eduard On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <[email protected]> wrote:
On 11 Sep 2016, at 19:24, Vincent Massol <[email protected]> wrote:
Hi devs,
I’d like to propose: * move out the Chart Macro + Renderer to Contrib since it’s not core. * still depend on it in the XE distribution for now. However if everyone feels that it’s not needed to have it by default for users and that it’s better to let them install it, I’m also fine. But right now I prefer to have it by default.
WDYT?
hmm there’s a small problem… Right now the Active Installs module uses the chart macro…
And Statistics UI too. I guess this one could be moved to contrib easily (we don’t bundle it anymore by defaultà.
However for ActiveInstalls it’s more complex, unless we don’t want to consider it core but I don’t think we want that…
So it means either we stop using the chart macro there (which would be a shame) or we consider the chart macro core…
Any idea?
Thanks -Vincent
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Edy,
On 13 Sep 2016, at 18:03, Eduard Moraru <[email protected]> wrote:
Hi,
Let`s think about active installs. The client module (i.e. the one doing the work and reporting) can be considered core, but the server module (the one receiving and showing a UI of the collected data) is not really core and can be moved to contrib. This will also fix the chart macro issue, since it's the server/ui module depending on it and not the client-api one.
Indeed you’re completely right! Don’t know why I didn’t think about this :) Thanks -Vincent
Thanks, Eduard
On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <[email protected]> wrote:
On 11 Sep 2016, at 19:24, Vincent Massol <[email protected]> wrote:
Hi devs,
I’d like to propose: * move out the Chart Macro + Renderer to Contrib since it’s not core. * still depend on it in the XE distribution for now. However if everyone feels that it’s not needed to have it by default for users and that it’s better to let them install it, I’m also fine. But right now I prefer to have it by default.
WDYT?
hmm there’s a small problem… Right now the Active Installs module uses the chart macro…
And Statistics UI too. I guess this one could be moved to contrib easily (we don’t bundle it anymore by defaultà.
However for ActiveInstalls it’s more complex, unless we don’t want to consider it core but I don’t think we want that…
So it means either we stop using the chart macro there (which would be a shame) or we consider the chart macro core…
Any idea?
Thanks -Vincent
Thanks -Vincent
On 13 Sep 2016, at 18:24, Vincent Massol <[email protected]> wrote:
Hi Edy,
On 13 Sep 2016, at 18:03, Eduard Moraru <[email protected]> wrote:
Hi,
Let`s think about active installs. The client module (i.e. the one doing the work and reporting) can be considered core, but the server module (the one receiving and showing a UI of the collected data) is not really core and can be moved to contrib. This will also fix the chart macro issue, since it's the server/ui module depending on it and not the client-api one.
Indeed you’re completely right! Don’t know why I didn’t think about this :)
Now that said, we might want to have other core stuff use the chart macro in the future. Are we really sure we’ll never want to use the chart macro in any core UI? Thanks -Vincent
Thanks -Vincent
Thanks, Eduard
On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <[email protected]> wrote:
On 11 Sep 2016, at 19:24, Vincent Massol <[email protected]> wrote:
Hi devs,
I’d like to propose: * move out the Chart Macro + Renderer to Contrib since it’s not core. * still depend on it in the XE distribution for now. However if everyone feels that it’s not needed to have it by default for users and that it’s better to let them install it, I’m also fine. But right now I prefer to have it by default.
WDYT?
hmm there’s a small problem… Right now the Active Installs module uses the chart macro…
And Statistics UI too. I guess this one could be moved to contrib easily (we don’t bundle it anymore by defaultà.
However for ActiveInstalls it’s more complex, unless we don’t want to consider it core but I don’t think we want that…
So it means either we stop using the chart macro there (which would be a shame) or we consider the chart macro core…
Any idea?
Thanks -Vincent
Thanks -Vincent
Can't really be sure. Anyway we have plenty of stuff to move so if there is a doubt we can keep this one for later :) On Tue, Sep 13, 2016 at 6:37 PM, Vincent Massol <[email protected]> wrote:
On 13 Sep 2016, at 18:24, Vincent Massol <[email protected]> wrote:
Hi Edy,
On 13 Sep 2016, at 18:03, Eduard Moraru <[email protected]> wrote:
Hi,
Let`s think about active installs. The client module (i.e. the one doing the work and reporting) can be considered core, but the server module (the one receiving and showing a UI of the collected data) is not really core and can be moved to contrib. This will also fix the chart macro issue, since it's the server/ui module depending on it and not the client-api one.
Indeed you’re completely right! Don’t know why I didn’t think about this :)
Now that said, we might want to have other core stuff use the chart macro in the future.
Are we really sure we’ll never want to use the chart macro in any core UI?
Thanks -Vincent
Thanks -Vincent
Thanks, Eduard
On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <[email protected]> wrote:
On 11 Sep 2016, at 19:24, Vincent Massol <[email protected]> wrote:
Hi devs,
I’d like to propose: * move out the Chart Macro + Renderer to Contrib since it’s not core. * still depend on it in the XE distribution for now. However if everyone feels that it’s not needed to have it by default for users and that it’s better to let them install it, I’m also fine. But right now I prefer to have it by default.
WDYT?
hmm there’s a small problem… Right now the Active Installs module uses the chart macro…
And Statistics UI too. I guess this one could be moved to contrib easily (we don’t bundle it anymore by defaultà.
However for ActiveInstalls it’s more complex, unless we don’t want to consider it core but I don’t think we want that…
So it means either we stop using the chart macro there (which would be a shame) or we consider the chart macro core…
Any idea?
Thanks -Vincent
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Tue, Sep 13, 2016 at 7:37 PM, Vincent Massol <[email protected]> wrote:
On 13 Sep 2016, at 18:24, Vincent Massol <[email protected]> wrote:
Hi Edy,
On 13 Sep 2016, at 18:03, Eduard Moraru <[email protected]> wrote:
Hi,
Let`s think about active installs. The client module (i.e. the one doing the work and reporting) can be considered core, but the server module (the one receiving and showing a UI of the collected data) is not really core and can be moved to contrib. This will also fix the chart macro issue, since it's the server/ui module depending on it and not the client-api one.
Indeed you’re completely right! Don’t know why I didn’t think about this :)
Now that said, we might want to have other core stuff use the chart macro in the future.
Are we really sure we’ll never want to use the chart macro in any core UI?
Are we really sure that this strategy is realistic? I mean, if one core module needs at some point, for some remote feature, to depend on the chart macro, does that automatically make the chart macro core? IMO no, otherwise we end up saying that all dependencies of core modules are core as well (could even argue the need to control the sources of all those dependencies as well), which would be obviously bad. This question probably leads back to the definition of core and what it implies. Thanks, Eduard
Thanks -Vincent
Thanks -Vincent
Thanks, Eduard
On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <[email protected]> wrote:
On 11 Sep 2016, at 19:24, Vincent Massol <[email protected]> wrote:
Hi devs,
I’d like to propose: * move out the Chart Macro + Renderer to Contrib since it’s not core. * still depend on it in the XE distribution for now. However if
everyone
feels that it’s not needed to have it by default for users and that it’s better to let them install it, I’m also fine. But right now I prefer to have it by default.
WDYT?
hmm there’s a small problem… Right now the Active Installs module uses the chart macro…
And Statistics UI too. I guess this one could be moved to contrib easily (we don’t bundle it anymore by defaultà.
However for ActiveInstalls it’s more complex, unless we don’t want to consider it core but I don’t think we want that…
So it means either we stop using the chart macro there (which would be a shame) or we consider the chart macro core…
Any idea?
Thanks -Vincent
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 13 Sep 2016, at 20:49, Eduard Moraru <[email protected]> wrote:
On Tue, Sep 13, 2016 at 7:37 PM, Vincent Massol <[email protected]> wrote:
On 13 Sep 2016, at 18:24, Vincent Massol <[email protected]> wrote:
Hi Edy,
On 13 Sep 2016, at 18:03, Eduard Moraru <[email protected]> wrote:
Hi,
Let`s think about active installs. The client module (i.e. the one doing the work and reporting) can be considered core, but the server module (the one receiving and showing a UI of the collected data) is not really core and can be moved to contrib. This will also fix the chart macro issue, since it's the server/ui module depending on it and not the client-api one.
Indeed you’re completely right! Don’t know why I didn’t think about this :)
Now that said, we might want to have other core stuff use the chart macro in the future.
Are we really sure we’ll never want to use the chart macro in any core UI?
Are we really sure that this strategy is realistic? I mean, if one core module needs at some point, for some remote feature, to depend on the chart macro, does that automatically make the chart macro core? IMO no
IMO it does. I don’t see how a core module could depend on a non core module. By definition if a module depends on another, it means that the module that it depends on is even “more core” than itself… And there’s no more core than core :)
, otherwise we end up saying that all dependencies of core modules are core as well (could even argue the need to control the sources of all those dependencies as well), which would be obviously bad.
Why is it bad? I don’t know any other definition and I’ve never heard of anything different done elsewhere. For me you only have 2 options if you find that a core module requires a dep on a currently non core module: 1) Make that non core module a core module (ie move it) 2) Make the core module non core (ie move it out of core)
This question probably leads back to the definition of core and what it implies.
We have a pretty good definition of core already: - All modules that make up the base distribution. - Modules maintained and developed by the XWiki Core Deve team (i.e. located in a repo in the XWiki organization on github) As time progresses and as we’re able to reduce hard-coded and artifical dependencies in core modules, we can extract more and more as non core. The only option that I see would be to consider that we can core modules that are located outside of the XWiki organization on github but I don’t feel that it is very convenient. It would scatter core modules. It feels better to have all core modules grouped together in a single place, especially since they should be released together. In conclusion: we need to be very careful about modules that we extract from the core since we don’t want to have to play yo-yo and move them back later in the future, as much as possible. Better be conservative when in doubt. For the case at hand, I wouldn’t move the chart macro for now. It seems core enough. Same for the code macro (unfortunately, since that means keeping the jython dep in the core too). Another thought just for the sake of mentioning it: * We could consider that all the UIs that are currently in xwiki-platform are not core and that only the APIs are core. This would mean that the base distribution would lead to an empty wiki. And all UIs would be brought by the flavors. * The consequence is that a lot of macros could be moved out: chart, code, etc. However this is a bit too drastic and harsh to do ATM IMO. So I don’t think it would be a good idea FTM. Thanks -Vincent
Thanks, Eduard
Thanks -Vincent
Thanks -Vincent
Thanks, Eduard
On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <[email protected]> wrote:
On 11 Sep 2016, at 19:24, Vincent Massol <[email protected]> wrote:
Hi devs,
I’d like to propose: * move out the Chart Macro + Renderer to Contrib since it’s not core. * still depend on it in the XE distribution for now. However if
everyone
feels that it’s not needed to have it by default for users and that it’s better to let them install it, I’m also fine. But right now I prefer to have it by default.
WDYT?
hmm there’s a small problem… Right now the Active Installs module uses the chart macro…
And Statistics UI too. I guess this one could be moved to contrib easily (we don’t bundle it anymore by defaultà.
However for ActiveInstalls it’s more complex, unless we don’t want to consider it core but I don’t think we want that…
So it means either we stop using the chart macro there (which would be a shame) or we consider the chart macro core…
Any idea?
Thanks -Vincent
Thanks -Vincent
On Tue, Sep 13, 2016 at 10:29 PM, Vincent Massol <[email protected]> wrote:
On 13 Sep 2016, at 20:49, Eduard Moraru <[email protected]> wrote:
On Tue, Sep 13, 2016 at 7:37 PM, Vincent Massol <[email protected]> wrote:
On 13 Sep 2016, at 18:24, Vincent Massol <[email protected]> wrote:
Hi Edy,
On 13 Sep 2016, at 18:03, Eduard Moraru <[email protected]> wrote:
Hi,
Let`s think about active installs. The client module (i.e. the one doing the work and reporting) can be considered core, but the server module (the one receiving and showing a UI of the collected data) is not really core and can be moved to contrib. This will also fix the chart macro issue, since it's the server/ui module depending on it and not the client-api one.
Indeed you’re completely right! Don’t know why I didn’t think about this :)
Now that said, we might want to have other core stuff use the chart macro in the future.
Are we really sure we’ll never want to use the chart macro in any core UI?
Are we really sure that this strategy is realistic? I mean, if one core module needs at some point, for some remote feature, to depend on the chart macro, does that automatically make the chart macro core? IMO no
IMO it does. I don’t see how a core module could depend on a non core module. By definition if a module depends on another, it means that the module that it depends on is even “more core” than itself… And there’s no more core than core :)
, otherwise we end up saying that all dependencies of core modules are core as well (could even argue the need to control the sources of all those dependencies as well), which would be obviously bad.
Why is it bad? I don’t know any other definition and I’ve never heard of anything different done elsewhere.
For me you only have 2 options if you find that a core module requires a dep on a currently non core module: 1) Make that non core module a core module (ie move it) 2) Make the core module non core (ie move it out of core)
This question probably leads back to the definition of core and what it implies.
We have a pretty good definition of core already: - All modules that make up the base distribution.
- Modules maintained and developed by the XWiki Core Deve team (i.e. located in a repo in the XWiki organization on github)
About that, you did not answered my comment on the fact that you plan to put "Knownledge Base" flavor (which will depends on various Contrib extensions) in xwiki-platform.
As time progresses and as we’re able to reduce hard-coded and artifical dependencies in core modules, we can extract more and more as non core.
The only option that I see would be to consider that we can core modules that are located outside of the XWiki organization on github but I don’t feel that it is very convenient. It would scatter core modules. It feels better to have all core modules grouped together in a single place, especially since they should be released together.
In conclusion: we need to be very careful about modules that we extract from the core since we don’t want to have to play yo-yo and move them back later in the future, as much as possible. Better be conservative when in doubt.
For the case at hand, I wouldn’t move the chart macro for now. It seems core enough. Same for the code macro (unfortunately, since that means keeping the jython dep in the core too).
Another thought just for the sake of mentioning it: * We could consider that all the UIs that are currently in xwiki-platform are not core and that only the APIs are core. This would mean that the base distribution would lead to an empty wiki. And all UIs would be brought by the flavors. * The consequence is that a lot of macros could be moved out: chart, code, etc.
However this is a bit too drastic and harsh to do ATM IMO. So I don’t think it would be a good idea FTM.
Thanks -Vincent
Thanks, Eduard
Thanks -Vincent
Thanks -Vincent
Thanks, Eduard
On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <[email protected]> wrote:
> On 11 Sep 2016, at 19:24, Vincent Massol <[email protected]> wrote: > > Hi devs, > > I’d like to propose: > * move out the Chart Macro + Renderer to Contrib since it’s not core. > * still depend on it in the XE distribution for now. However if
everyone
feels that it’s not needed to have it by default for users and that it’s better to let them install it, I’m also fine. But right now I prefer to have it by default. > > WDYT?
hmm there’s a small problem… Right now the Active Installs module uses the chart macro…
And Statistics UI too. I guess this one could be moved to contrib easily (we don’t bundle it anymore by defaultà.
However for ActiveInstalls it’s more complex, unless we don’t want to consider it core but I don’t think we want that…
So it means either we stop using the chart macro there (which would be a shame) or we consider the chart macro core…
Any idea?
Thanks -Vincent
> Thanks > -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 14 Sep 2016, at 07:58, Thomas Mortagne <[email protected]> wrote:
[snip]
We have a pretty good definition of core already: - All modules that make up the base distribution.
- Modules maintained and developed by the XWiki Core Deve team (i.e. located in a repo in the XWiki organization on github)
About that, you did not answered my comment on the fact that you plan to put "Knownledge Base" flavor (which will depends on various Contrib extensions) in xwiki-platform.
Sorry I must have missed it. You have a markmail link to your comment so I can see the context? For me it’s not a major problem to have a flavor inside platform that depends on contrib stuff. We’re already doing this with xwiki-enterprise and the KB flavor is the same as xwiki-enterprise (moved to xwiki-platform). Having KB in xwiki-platform is just a way to clearly show that this flavor is maintained by the XWiki Core dev team. And to be able to maintain its quality since this is the main flavor that people will use. Actually I wouldn’t mind either if we wanted to move it out of the xwiki github org and put in xwik-contrib. Cons: - a bit less control on its quality - additional release work for the Release Manager. We need to at least release it at the same time as we release new versions of the base distribution so that our users have something they can use. - we might need to separate the RN for the base distribution from the RN for the KB flavor (since the KB flavor can have more releases and it would no longer be “core”). - the xwiki github org doesn’t deliver any immediately usable distribution. Pros: - ability to release the KB flavor more often than the base distribution - ability to let other member of the community contribute more easily to it - we no longer have any contrib dependency inside the XWiki github organization The pros are tempting :) WDYT? Thanks -Vincent [snip]
On Wed, Sep 14, 2016 at 8:29 AM, Vincent Massol <[email protected]> wrote:
On 14 Sep 2016, at 07:58, Thomas Mortagne <[email protected]> wrote:
[snip]
We have a pretty good definition of core already: - All modules that make up the base distribution.
- Modules maintained and developed by the XWiki Core Deve team (i.e. located in a repo in the XWiki organization on github)
About that, you did not answered my comment on the fact that you plan to put "Knownledge Base" flavor (which will depends on various Contrib extensions) in xwiki-platform.
Sorry I must have missed it. You have a markmail link to your comment so I can see the context?
http://markmail.org/message/ebcsjq6klye4oxn4
For me it’s not a major problem to have a flavor inside platform that depends on contrib stuff. We’re already doing this with xwiki-enterprise and the KB flavor is the same as xwiki-enterprise (moved to xwiki-platform).
I was just pointing out that you just defined core extensions as extensions being "located in a repo in the XWiki organization on github".
Having KB in xwiki-platform is just a way to clearly show that this flavor is maintained by the XWiki Core dev team. And to be able to maintain its quality since this is the main flavor that people will use.
Actually I wouldn’t mind either if we wanted to move it out of the xwiki github org and put in xwik-contrib.
Cons: - a bit less control on its quality - additional release work for the Release Manager. We need to at least release it at the same time as we release new versions of the base distribution so that our users have something they can use. - we might need to separate the RN for the base distribution from the RN for the KB flavor (since the KB flavor can have more releases and it would no longer be “core”). - the xwiki github org doesn’t deliver any immediately usable distribution.
Pros: - ability to release the KB flavor more often than the base distribution - ability to let other member of the community contribute more easily to it - we no longer have any contrib dependency inside the XWiki github organization
The pros are tempting :)
WDYT?
Thanks -Vincent
[snip]
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 14 Sep 2016, at 09:27, Thomas Mortagne <[email protected]> wrote:
On Wed, Sep 14, 2016 at 8:29 AM, Vincent Massol <[email protected]> wrote:
On 14 Sep 2016, at 07:58, Thomas Mortagne <[email protected]> wrote:
[snip]
We have a pretty good definition of core already: - All modules that make up the base distribution.
- Modules maintained and developed by the XWiki Core Deve team (i.e. located in a repo in the XWiki organization on github)
About that, you did not answered my comment on the fact that you plan to put "Knownledge Base" flavor (which will depends on various Contrib extensions) in xwiki-platform.
Sorry I must have missed it. You have a markmail link to your comment so I can see the context?
Thanks
For me it’s not a major problem to have a flavor inside platform that depends on contrib stuff. We’re already doing this with xwiki-enterprise and the KB flavor is the same as xwiki-enterprise (moved to xwiki-platform).
I was just pointing out that you just defined core extensions as extensions being "located in a repo in the XWiki organization on github”.
Actually I wanted to say that it has to meet 2 criteria but I probably wasn’t clear that it was an “AND” and not an “OR”: “ We have a pretty good definition of core already: - All modules that make up the base distribution. - Modules maintained and developed by the XWiki Core Deve team (i.e. located in a repo in the XWiki organization on github) “ So the KB flavor doesn’t meet this definition (since it’s not in the base distribution). But anyway, let’s continue the discussion based on my answer where I listed some pros/cons that I see. I’m curious to see what you guys think and whether you think moving the KB flavor to xwiki-contrib is what we should do. Thanks -Vincent
Having KB in xwiki-platform is just a way to clearly show that this flavor is maintained by the XWiki Core dev team. And to be able to maintain its quality since this is the main flavor that people will use.
Actually I wouldn’t mind either if we wanted to move it out of the xwiki github org and put in xwik-contrib.
Cons: - a bit less control on its quality - additional release work for the Release Manager. We need to at least release it at the same time as we release new versions of the base distribution so that our users have something they can use. - we might need to separate the RN for the base distribution from the RN for the KB flavor (since the KB flavor can have more releases and it would no longer be “core”). - the xwiki github org doesn’t deliver any immediately usable distribution.
Pros: - ability to release the KB flavor more often than the base distribution - ability to let other member of the community contribute more easily to it - we no longer have any contrib dependency inside the XWiki github organization
The pros are tempting :)
WDYT?
Thanks -Vincent
[snip]
On Wed, Sep 14, 2016 at 9:36 AM, Vincent Massol <[email protected]> wrote:
On 14 Sep 2016, at 09:27, Thomas Mortagne <[email protected]> wrote:
On Wed, Sep 14, 2016 at 8:29 AM, Vincent Massol <[email protected]> wrote:
On 14 Sep 2016, at 07:58, Thomas Mortagne <[email protected]> wrote:
[snip]
We have a pretty good definition of core already: - All modules that make up the base distribution.
- Modules maintained and developed by the XWiki Core Deve team (i.e. located in a repo in the XWiki organization on github)
About that, you did not answered my comment on the fact that you plan to put "Knownledge Base" flavor (which will depends on various Contrib extensions) in xwiki-platform.
Sorry I must have missed it. You have a markmail link to your comment so I can see the context?
Thanks
For me it’s not a major problem to have a flavor inside platform that depends on contrib stuff. We’re already doing this with xwiki-enterprise and the KB flavor is the same as xwiki-enterprise (moved to xwiki-platform).
I was just pointing out that you just defined core extensions as extensions being "located in a repo in the XWiki organization on github”.
Actually I wanted to say that it has to meet 2 criteria but I probably wasn’t clear that it was an “AND” and not an “OR”:
“ We have a pretty good definition of core already: - All modules that make up the base distribution. - Modules maintained and developed by the XWiki Core Deve team (i.e. located in a repo in the XWiki organization on github) “
So the KB flavor doesn’t meet this definition (since it’s not in the base distribution).
But anyway, let’s continue the discussion based on my answer where I listed some pros/cons that I see.
I’m curious to see what you guys think and whether you think moving the KB flavor to xwiki-contrib is what we should do.
Thanks -Vincent
Having KB in xwiki-platform is just a way to clearly show that this flavor is maintained by the XWiki Core dev team. And to be able to maintain its quality since this is the main flavor that people will use.
Actually I wouldn’t mind either if we wanted to move it out of the xwiki github org and put in xwik-contrib.
Cons: - a bit less control on its quality - additional release work for the Release Manager. We need to at least release it at the same time as we release new versions of the base distribution so that our users have something they can use. - we might need to separate the RN for the base distribution from the RN for the KB flavor (since the KB flavor can have more releases and it would no longer be “core”).
- the xwiki github org doesn’t deliver any immediately usable distribution.
This is a bit misleading. What most people will download is the XWiki distribution on which you can select a flavor like "Knowledge Base" in the DW.
Pros: - ability to release the KB flavor more often than the base distribution
We discussed about speed up the release cycle of platform anyway.
- ability to let other member of the community contribute more easily to it
I'm not so sure about this plus a flavor is quite close to an empty shell anyway so there is not much to contribute to in practice.
- we no longer have any contrib dependency inside the XWiki github organization
The pros are tempting :)
WDYT?
IMO it's way too much work and too error prone to not sync with xwiki-platform release cycle what is going to be the XWiki Dev Team supported recommended default flavor. We just need to be more clear about the dependencies rules in xwiki organization and probably stop fighting over what "core" term means. For example we could simply say: * XWiki WAR and "Base Flavor" are not allowed to trigger any xwiki-contrib dependency * Like most flavors "Knownledge Base" flavor depends on "Base Flavor" and any other thing that make sense for its purpose * Since we want to make "Knownledge Base" flavor in sync with platform for now we keep it in platform (probably in its own top level xwiki-platform/xwiki-platform-knownledgebase folder) because it's a lot easier and safer like this. Maybe later we'll decide to give "Knownledge Base" its own life in Contrib (when there will be various good quality flavors in there probably) but we don't need to worry much that for now.
Thanks -Vincent
[snip]
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 with Thomas 2016-09-14 10:15 GMT+02:00 Thomas Mortagne <[email protected]>:
On Wed, Sep 14, 2016 at 9:36 AM, Vincent Massol <[email protected]> wrote:
On 14 Sep 2016, at 09:27, Thomas Mortagne <[email protected]>
wrote:
On Wed, Sep 14, 2016 at 8:29 AM, Vincent Massol <[email protected]>
wrote:
On 14 Sep 2016, at 07:58, Thomas Mortagne <[email protected]>
wrote:
[snip]
We have a pretty good definition of core already: - All modules that make up the base distribution.
- Modules maintained and developed by the XWiki Core Deve team (i.e.
located in a repo in the XWiki organization on github)
About that, you did not answered my comment on the fact that you plan to put "Knownledge Base" flavor (which will depends on various Contrib extensions) in xwiki-platform.
Sorry I must have missed it. You have a markmail link to your comment so I can see the context?
Thanks
For me it’s not a major problem to have a flavor inside platform that
depends on contrib stuff. We’re already doing this with xwiki-enterprise and the KB flavor is the same as xwiki-enterprise (moved to xwiki-platform).
I was just pointing out that you just defined core extensions as extensions being "located in a repo in the XWiki organization on github”.
Actually I wanted to say that it has to meet 2 criteria but I probably wasn’t clear that it was an “AND” and not an “OR”:
“ We have a pretty good definition of core already: - All modules that make up the base distribution. - Modules maintained and developed by the XWiki Core Deve team (i.e. located in a repo in the XWiki organization on github) “
So the KB flavor doesn’t meet this definition (since it’s not in the base distribution).
But anyway, let’s continue the discussion based on my answer where I listed some pros/cons that I see.
I’m curious to see what you guys think and whether you think moving the KB flavor to xwiki-contrib is what we should do.
Thanks -Vincent
Having KB in xwiki-platform is just a way to clearly show that this flavor is maintained by the XWiki Core dev team. And to be able to maintain its quality since this is the main flavor that people will use.
Actually I wouldn’t mind either if we wanted to move it out of the
xwiki github org and put in xwik-contrib.
Cons: - a bit less control on its quality - additional release work for the Release Manager. We need to at least
release it at the same time as we release new versions of the base distribution so that our users have something they can use.
- we might need to separate the RN for the base distribution from the RN for the KB flavor (since the KB flavor can have more releases and it would no longer be “core”).
- the xwiki github org doesn’t deliver any immediately usable distribution.
This is a bit misleading. What most people will download is the XWiki distribution on which you can select a flavor like "Knowledge Base" in the DW.
Pros: - ability to release the KB flavor more often than the base
distribution
We discussed about speed up the release cycle of platform anyway.
- ability to let other member of the community contribute more easily to it
I'm not so sure about this plus a flavor is quite close to an empty shell anyway so there is not much to contribute to in practice.
- we no longer have any contrib dependency inside the XWiki github organization
The pros are tempting :)
WDYT?
IMO it's way too much work and too error prone to not sync with xwiki-platform release cycle what is going to be the XWiki Dev Team supported recommended default flavor.
We just need to be more clear about the dependencies rules in xwiki organization and probably stop fighting over what "core" term means. For example we could simply say: * XWiki WAR and "Base Flavor" are not allowed to trigger any xwiki-contrib dependency * Like most flavors "Knownledge Base" flavor depends on "Base Flavor" and any other thing that make sense for its purpose * Since we want to make "Knownledge Base" flavor in sync with platform for now we keep it in platform (probably in its own top level xwiki-platform/xwiki-platform-knownledgebase folder) because it's a lot easier and safer like this. Maybe later we'll decide to give "Knownledge Base" its own life in Contrib (when there will be various good quality flavors in there probably) but we don't need to worry much that for now.
Thanks -Vincent
[snip]
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ 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
+1 On Tue, Sep 13, 2016 at 6:03 PM, Eduard Moraru <[email protected]> wrote:
Hi,
Let`s think about active installs. The client module (i.e. the one doing the work and reporting) can be considered core, but the server module (the one receiving and showing a UI of the collected data) is not really core and can be moved to contrib. This will also fix the chart macro issue, since it's the server/ui module depending on it and not the client-api one.
Thanks, Eduard
On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <[email protected]> wrote:
On 11 Sep 2016, at 19:24, Vincent Massol <[email protected]> wrote:
Hi devs,
I’d like to propose: * move out the Chart Macro + Renderer to Contrib since it’s not core. * still depend on it in the XE distribution for now. However if everyone feels that it’s not needed to have it by default for users and that it’s better to let them install it, I’m also fine. But right now I prefer to have it by default.
WDYT?
hmm there’s a small problem… Right now the Active Installs module uses the chart macro…
And Statistics UI too. I guess this one could be moved to contrib easily (we don’t bundle it anymore by defaultà.
However for ActiveInstalls it’s more complex, unless we don’t want to consider it core but I don’t think we want that…
So it means either we stop using the chart macro there (which would be a shame) or we consider the chart macro core…
Any idea?
Thanks -Vincent
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
-- Thomas Mortagne
participants (4)
-
Eduard Moraru -
Guillaume Delhumeau -
Thomas Mortagne -
Vincent Massol