13 Sep
2016
13 Sep
'16
6:03 p.m.
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 <vincent(a)massol.net> wrote:
On 11 Sep 2016, at 19:24, Vincent Massol
<vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
13 Sep
13 Sep
6:24 p.m.
New subject: [xwiki-devs] [Proposal] Move out Chart Macro + Renderer to Contrib
Hi Edy,
On 13 Sep 2016, at 18:03, Eduard Moraru
<enygma2002(a)gmail.com> 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 <vincent(a)massol.net> wrote:
>
>> On 11 Sep 2016, at 19:24, Vincent Massol <vincent(a)massol.net> 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
6:37 p.m.
New subject: [xwiki-devs] [Proposal] Move out Chart Macro + Renderer to Contrib
On 13 Sep 2016, at 18:24, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Edy,
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
On 13 Sep 2016, at 18:03, Eduard Moraru
<enygma2002(a)gmail.com> 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 <vincent(a)massol.net> wrote:
>
>> On 11 Sep 2016, at 19:24, Vincent Massol <vincent(a)massol.net> 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
6:41 p.m.
New subject: [xwiki-devs] [Proposal] Move out Chart Macro + Renderer to Contrib
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 <vincent(a)massol.net> wrote:
--
Thomas Mortagne
On 13 Sep 2016, at 18:24, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Edy,
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
On 13 Sep 2016, at 18:03, Eduard Moraru
<enygma2002(a)gmail.com> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Thanks,
Eduard
On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <vincent(a)massol.net> wrote:
>
>> On 11 Sep 2016, at 19:24, Vincent Massol <vincent(a)massol.net> 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
8:49 p.m.
New subject: [xwiki-devs] [Proposal] Move out Chart Macro + Renderer to Contrib
On Tue, Sep 13, 2016 at 7:37 PM, Vincent Massol <vincent(a)massol.net> wrote:
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
On 13 Sep 2016, at 18:24, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Edy,
> On 13 Sep 2016, at 18:03, Eduard Moraru <enygma2002(a)gmail.com> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks
-Vincent
> Thanks,
> Eduard
>
> On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>
>>
>>> On 11 Sep 2016, at 19:24, Vincent Massol <vincent(a)massol.net> 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
10:29 p.m.
New subject: [xwiki-devs] Core dependencies (was Re: [Proposal] Move out Chart Macro + Renderer to Contrib)
On 13 Sep 2016, at 20:49, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
On Tue, Sep 13, 2016 at 7:37 PM, Vincent Massol <vincent(a)massol.net> wrote:
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 :)
On 13 Sep 2016, at 18:24, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Edy,
> On 13 Sep 2016, at 18:03, Eduard Moraru <enygma2002(a)gmail.com> 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?
, 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 <vincent(a)massol.net>
> wrote:
>>>
>>>>
>>>>> On 11 Sep 2016, at 19:24, Vincent Massol <vincent(a)massol.net>
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
14 Sep
14 Sep
7:58 a.m.
New subject: [xwiki-devs] Core dependencies (was Re: [Proposal] Move out Chart Macro + Renderer to Contrib)
On Tue, Sep 13, 2016 at 10:29 PM, Vincent Massol <vincent(a)massol.net> wrote:
On 13 Sep 2016, at 20:49, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
On Tue, Sep 13, 2016 at 7:37 PM, Vincent Massol <vincent(a)massol.net> wrote:
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 :)
On 13 Sep 2016, at 18:24, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Edy,
> On 13 Sep 2016, at 18:03, Eduard Moraru <enygma2002(a)gmail.com> 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?
, 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
--
Thomas Mortagne
Thanks,
Eduard
>
> Thanks
> -Vincent
>
>> Thanks
>> -Vincent
>>
>>> Thanks,
>>> Eduard
>>>
>>> On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
>>>
>>>>
>>>>> On 11 Sep 2016, at 19:24, Vincent Massol <vincent(a)massol.net>
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:29 a.m.
New subject: [xwiki-devs] Core dependencies (was Re: [Proposal] Move out Chart Macro + Renderer to Contrib)
On 14 Sep 2016, at 07:58, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> 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.
9:27 a.m.
New subject: [xwiki-devs] Core dependencies (was Re: [Proposal] Move out Chart Macro + Renderer to Contrib)
On Wed, Sep 14, 2016 at 8:29 AM, Vincent Massol <vincent(a)massol.net> wrote:
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
On 14 Sep 2016, at 07:58, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> 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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
9:36 a.m.
New subject: [xwiki-devs] Core dependencies (was Re: [Proposal] Move out Chart Macro + Renderer to Contrib)
On 14 Sep 2016, at 09:27, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Wed, Sep 14, 2016 at 8:29 AM, Vincent Massol <vincent(a)massol.net> wrote:
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
Thanks
On 14 Sep 2016, at 07:58, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> 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.
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]
10:15 a.m.
New subject: [xwiki-devs] Core dependencies (was Re: [Proposal] Move out Chart Macro + Renderer to Contrib)
On Wed, Sep 14, 2016 at 9:36 AM, Vincent Massol <vincent(a)massol.net> wrote:
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”).
--
Thomas Mortagne
On 14 Sep 2016, at 09:27, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Wed, Sep 14, 2016 at 8:29 AM, Vincent Massol <vincent(a)massol.net> wrote:
http://markmail.org/message/ebcsjq6klye4oxn4
Thanks
On 14 Sep 2016, at 07:58, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> 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).
I was just pointing out that you just defined core extensions as
extensions being "located in a repo in the XWiki organization on
github”. >> - 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
11:16 a.m.
New subject: [xwiki-devs] Core dependencies (was Re: [Proposal] Move out Chart Macro + Renderer to Contrib)
+1 with Thomas
2016-09-14 10:15 GMT+02:00 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
On Wed, Sep 14, 2016 at 9:36 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
wasn’t
clear that it was an “AND” and not an “OR”:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
> On 14 Sep 2016, at 09:27, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>
> On Wed, Sep 14, 2016 at 8:29 AM, Vincent Massol <vincent(a)massol.net>
wrote:
>>
>>> On 14 Sep 2016, at 07:58, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
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
“
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
13 Sep
13 Sep
6:33 p.m.
New subject: [xwiki-devs] [Proposal] Move out Chart Macro + Renderer to Contrib
+1
On Tue, Sep 13, 2016 at 6:03 PM, Eduard Moraru <enygma2002(a)gmail.com> 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 <vincent(a)massol.net> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
On 11 Sep 2016, at 19:24, Vincent Massol
<vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3021
days inactive
3022
days old
12 comments
4 participants
participants (4)
-
Eduard Moraru -
Guillaume Delhumeau -
Thomas Mortagne -
Vincent Massol