[xwiki-devs] [VOTE] Stop bundling legacy .jar files in enterprise and manager.
Hi, I understand we agreed in http://lists.xwiki.org/pipermail/devs/2012-March/050172.html to stop bundling legacy modules by default. What was not so clear is how we should do this. I want to remove the modules from XE and Manager, and document the method of downloading them from maven.xwiki.org and replacing the existing .jar files with them. Why: #1. Not removing API is obviously unsustainable in the long term. #2. Replacing core .jar files has been judged to be beyond the scope of the extension manager. Whether we want to support overriding classes using extensions as a "function hooking" mechanism is a possible topic for future discussion. #3. Replacing .jar files in the .war is not an excessively complex task, we ask users to open the war file for configuring a database or adding JDBC connectors, cases where there is much less technical need to require opening the .war file. Here's my +1 to remove it ASAP, for 4.1M2 if we can get the tests passing. Caleb
Hi Caleb, On May 22, 2012, at 5:00 PM, Caleb James DeLisle wrote:
Hi,
I understand we agreed in http://lists.xwiki.org/pipermail/devs/2012-March/050172.html to stop bundling legacy modules by default. What was not so clear is how we should do this.
I want to remove the modules from XE and Manager, and document the method of downloading them from maven.xwiki.org and replacing the existing .jar files with them.
It's not enough IMO. Here's a likely scenario: * Users will download the version without legacy modules. * Then they'll use the Extension Manager to install extensions from extensions.xwiki.org * The extensions will fail * Users will ditch xwiki since it just doesn't work and the quality is perceived as not good enough. We need to solve this before we can stop bundling the legacy modules IMO.
Why:
#1. Not removing API is obviously unsustainable in the long term.
#2. Replacing core .jar files has been judged to be beyond the scope of the extension manager. Whether we want to support overriding classes using extensions as a "function hooking" mechanism is a possible topic for future discussion.
#3. Replacing .jar files in the .war is not an excessively complex task, we ask users to open the war file for configuring a database or adding JDBC connectors, cases where there is much less technical need to require opening the .war file.
Here's my +1 to remove it ASAP, for 4.1M2 if we can get the tests passing.
-1 till we solve the question above. I'd rather keep legacy modules than have dissatisfied users. Thanks -Vincent
Caleb
On Tue, May 22, 2012 at 5:58 PM, Vincent Massol <[email protected]> wrote:
Hi Caleb,
On May 22, 2012, at 5:00 PM, Caleb James DeLisle wrote:
Hi,
I understand we agreed in http://lists.xwiki.org/pipermail/devs/2012-March/050172.html to stop bundling legacy modules by default. What was not so clear is how we should do this.
I want to remove the modules from XE and Manager, and document the method of downloading them from maven.xwiki.org and replacing the existing .jar files with them.
It's not enough IMO. Here's a likely scenario:
* Users will download the version without legacy modules. * Then they'll use the Extension Manager to install extensions from extensions.xwiki.org * The extensions will fail * Users will ditch xwiki since it just doesn't work and the quality is perceived as not good enough.
We need to solve this before we can stop bundling the legacy modules IMO.
Why:
#1. Not removing API is obviously unsustainable in the long term.
#2. Replacing core .jar files has been judged to be beyond the scope of the extension manager. Whether we want to support overriding classes using extensions as a "function hooking" mechanism is a possible topic for future discussion.
#3. Replacing .jar files in the .war is not an excessively complex task, we ask users to open the war file for configuring a database or adding JDBC connectors, cases where there is much less technical need to require opening the .war file.
Here's my +1 to remove it ASAP, for 4.1M2 if we can get the tests passing.
-1 till we solve the question above. I'd rather keep legacy modules than have dissatisfied users.
-1 for the same reason. Thanks, Marius
Thanks -Vincent
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-1 too, not bundling at least core extensions legacy modules will make EM more or less unusable for many extension older than the current version right now. On Wed, May 23, 2012 at 9:43 AM, Marius Dumitru Florea <[email protected]> wrote:
On Tue, May 22, 2012 at 5:58 PM, Vincent Massol <[email protected]> wrote:
Hi Caleb,
On May 22, 2012, at 5:00 PM, Caleb James DeLisle wrote:
Hi,
I understand we agreed in http://lists.xwiki.org/pipermail/devs/2012-March/050172.html to stop bundling legacy modules by default. What was not so clear is how we should do this.
I want to remove the modules from XE and Manager, and document the method of downloading them from maven.xwiki.org and replacing the existing .jar files with them.
It's not enough IMO. Here's a likely scenario:
* Users will download the version without legacy modules. * Then they'll use the Extension Manager to install extensions from extensions.xwiki.org * The extensions will fail * Users will ditch xwiki since it just doesn't work and the quality is perceived as not good enough.
We need to solve this before we can stop bundling the legacy modules IMO.
Why:
#1. Not removing API is obviously unsustainable in the long term.
#2. Replacing core .jar files has been judged to be beyond the scope of the extension manager. Whether we want to support overriding classes using extensions as a "function hooking" mechanism is a possible topic for future discussion.
#3. Replacing .jar files in the .war is not an excessively complex task, we ask users to open the war file for configuring a database or adding JDBC connectors, cases where there is much less technical need to require opening the .war file.
Here's my +1 to remove it ASAP, for 4.1M2 if we can get the tests passing.
-1 till we solve the question above. I'd rather keep legacy modules than have dissatisfied users.
-1 for the same reason.
Thanks, Marius
Thanks -Vincent
Caleb
_______________________________________________ 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
Could they be shipped but deactivated by default? And let the EM activate them? Sounds normal for an EM job though I agree it's an extra work. Making it visible is a good way to encourage the people to upgrade their extensions or make them "visible is old grumps". paul Le 23 mai 2012 à 10:34, Thomas Mortagne a écrit :
-1 too, not bundling at least core extensions legacy modules will make EM more or less unusable for many extension older than the current version right now.
On Wed, May 23, 2012 at 9:43 AM, Marius Dumitru Florea <[email protected]> wrote:
On Tue, May 22, 2012 at 5:58 PM, Vincent Massol <[email protected]> wrote:
Hi Caleb,
On May 22, 2012, at 5:00 PM, Caleb James DeLisle wrote:
Hi,
I understand we agreed in http://lists.xwiki.org/pipermail/devs/2012-March/050172.html to stop bundling legacy modules by default. What was not so clear is how we should do this.
I want to remove the modules from XE and Manager, and document the method of downloading them from maven.xwiki.org and replacing the existing .jar files with them.
It's not enough IMO. Here's a likely scenario:
* Users will download the version without legacy modules. * Then they'll use the Extension Manager to install extensions from extensions.xwiki.org * The extensions will fail * Users will ditch xwiki since it just doesn't work and the quality is perceived as not good enough.
We need to solve this before we can stop bundling the legacy modules IMO.
Why:
#1. Not removing API is obviously unsustainable in the long term.
#2. Replacing core .jar files has been judged to be beyond the scope of the extension manager. Whether we want to support overriding classes using extensions as a "function hooking" mechanism is a possible topic for future discussion.
#3. Replacing .jar files in the .war is not an excessively complex task, we ask users to open the war file for configuring a database or adding JDBC connectors, cases where there is much less technical need to require opening the .war file.
Here's my +1 to remove it ASAP, for 4.1M2 if we can get the tests passing.
-1 till we solve the question above. I'd rather keep legacy modules than have dissatisfied users.
-1 for the same reason.
Thanks, Marius
Thanks -Vincent
Caleb
_______________________________________________ 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
3 -1's so there is definitely plenty of agreement in this case. My understanding is that in "Distribute without legacy modules by default" "distribute" means "distribute [enterprise and manager]", which would make this a reversal of the agreement voted upon here: http://lists.xwiki.org/pipermail/devs/2012-April/050386.html At any rate I am curious as to whether the community wants to ever remove anything. If we want to get to the point of removing things then I want to help, if we don't want to then I will accept it. The way I see it, breaking API and removing code is like taking out the garbage. When you do it, you stink and nobody is your friend. If you don't do it, everything stinks but it does so a little at a time. It seems to work reasonably well.. Oracle, Sun and Microsoft have been doing it for years. All I care about is that we have a plan, if we want to remove stuff then lets make it happen, if we want to never remove anything then lets make it a conscious decision. I don't like the idea of having the decision make itself while we put it off. Caleb On 05/23/2012 06:09 AM, Paul Libbrecht wrote:
Could they be shipped but deactivated by default? And let the EM activate them? Sounds normal for an EM job though I agree it's an extra work. Making it visible is a good way to encourage the people to upgrade their extensions or make them "visible is old grumps".
paul
Le 23 mai 2012 à 10:34, Thomas Mortagne a écrit :
-1 too, not bundling at least core extensions legacy modules will make EM more or less unusable for many extension older than the current version right now.
On Wed, May 23, 2012 at 9:43 AM, Marius Dumitru Florea <[email protected]> wrote:
On Tue, May 22, 2012 at 5:58 PM, Vincent Massol <[email protected]> wrote:
Hi Caleb,
On May 22, 2012, at 5:00 PM, Caleb James DeLisle wrote:
Hi,
I understand we agreed in http://lists.xwiki.org/pipermail/devs/2012-March/050172.html to stop bundling legacy modules by default. What was not so clear is how we should do this.
I want to remove the modules from XE and Manager, and document the method of downloading them from maven.xwiki.org and replacing the existing .jar files with them.
It's not enough IMO. Here's a likely scenario:
* Users will download the version without legacy modules. * Then they'll use the Extension Manager to install extensions from extensions.xwiki.org * The extensions will fail * Users will ditch xwiki since it just doesn't work and the quality is perceived as not good enough.
We need to solve this before we can stop bundling the legacy modules IMO.
Why:
#1. Not removing API is obviously unsustainable in the long term.
#2. Replacing core .jar files has been judged to be beyond the scope of the extension manager. Whether we want to support overriding classes using extensions as a "function hooking" mechanism is a possible topic for future discussion.
#3. Replacing .jar files in the .war is not an excessively complex task, we ask users to open the war file for configuring a database or adding JDBC connectors, cases where there is much less technical need to require opening the .war file.
Here's my +1 to remove it ASAP, for 4.1M2 if we can get the tests passing.
-1 till we solve the question above. I'd rather keep legacy modules than have dissatisfied users.
-1 for the same reason.
Thanks, Marius
Thanks -Vincent
Caleb
_______________________________________________ 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 _______________________________________________ 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 May 23, 2012, at 1:25 PM, Caleb James DeLisle wrote:
3 -1's so there is definitely plenty of agreement in this case.
My understanding is that in "Distribute without legacy modules by default" "distribute" means "distribute [enterprise and manager]", which would make this a reversal of the agreement voted upon here: http://lists.xwiki.org/pipermail/devs/2012-April/050386.html
At any rate I am curious as to whether the community wants to ever remove anything. If we want to get to the point of removing things then I want to help, if we don't want to then I will accept it.
- We vote to never remove/break things (except on rare occasions) - However we've also decided to not stink by moving things to Legacy and using aspects ;) - Now the next step is to decide how we make users aware of deprecated stuff (removing from the distribution is one way, there are plenty of other ways - warnings in XE when using a deprecated API - Deprecated API Center, flag dependencies using deprecated code, etc). We just need someone to propose something that can work in an acceptable manner.
The way I see it, breaking API and removing code is like taking out the garbage. When you do it, you stink and nobody is your friend. If you don't do it, everything stinks but it does so a little at a time. It seems to work reasonably well.. Oracle, Sun and Microsoft have been doing it for years.
Not true, Sun/Oracle have not done that for Java. They've always kept backward compat. and taken that seriously. I don't know too much about Microsoft but I can't imagine any development platform breaking users without offering an upgrade path.
All I care about is that we have a plan, if we want to remove stuff then lets make it happen, if we want to never remove anything then lets make it a conscious decision. I don't like the idea of having the decision make itself while we put it off.
We all agree we need to find a solution. To summarize, ATM, we all agree about the general strategy, we just haven't found an acceptable implementation yet :) Thanks -Vincent
Caleb
On 05/23/2012 06:09 AM, Paul Libbrecht wrote:
Could they be shipped but deactivated by default? And let the EM activate them? Sounds normal for an EM job though I agree it's an extra work. Making it visible is a good way to encourage the people to upgrade their extensions or make them "visible is old grumps".
paul
Le 23 mai 2012 à 10:34, Thomas Mortagne a écrit :
-1 too, not bundling at least core extensions legacy modules will make EM more or less unusable for many extension older than the current version right now.
On Wed, May 23, 2012 at 9:43 AM, Marius Dumitru Florea <[email protected]> wrote:
On Tue, May 22, 2012 at 5:58 PM, Vincent Massol <[email protected]> wrote:
Hi Caleb,
On May 22, 2012, at 5:00 PM, Caleb James DeLisle wrote:
Hi,
I understand we agreed in http://lists.xwiki.org/pipermail/devs/2012-March/050172.html to stop bundling legacy modules by default. What was not so clear is how we should do this.
I want to remove the modules from XE and Manager, and document the method of downloading them from maven.xwiki.org and replacing the existing .jar files with them.
It's not enough IMO. Here's a likely scenario:
* Users will download the version without legacy modules. * Then they'll use the Extension Manager to install extensions from extensions.xwiki.org * The extensions will fail * Users will ditch xwiki since it just doesn't work and the quality is perceived as not good enough.
We need to solve this before we can stop bundling the legacy modules IMO.
Why:
#1. Not removing API is obviously unsustainable in the long term.
#2. Replacing core .jar files has been judged to be beyond the scope of the extension manager. Whether we want to support overriding classes using extensions as a "function hooking" mechanism is a possible topic for future discussion.
#3. Replacing .jar files in the .war is not an excessively complex task, we ask users to open the war file for configuring a database or adding JDBC connectors, cases where there is much less technical need to require opening the .war file.
Here's my +1 to remove it ASAP, for 4.1M2 if we can get the tests passing.
-1 till we solve the question above. I'd rather keep legacy modules than have dissatisfied users.
-1 for the same reason.
Thanks, Marius
Thanks -Vincent
Caleb
On 05/23/2012 07:43 AM, Vincent Massol wrote:
On May 23, 2012, at 1:25 PM, Caleb James DeLisle wrote:
3 -1's so there is definitely plenty of agreement in this case.
My understanding is that in "Distribute without legacy modules by default" "distribute" means "distribute [enterprise and manager]", which would make this a reversal of the agreement voted upon here: http://lists.xwiki.org/pipermail/devs/2012-April/050386.html
At any rate I am curious as to whether the community wants to ever remove anything. If we want to get to the point of removing things then I want to help, if we don't want to then I will accept it.
- We vote to never remove/break things (except on rare occasions) - However we've also decided to not stink by moving things to Legacy and using aspects ;) - Now the next step is to decide how we make users aware of deprecated stuff (removing from the distribution is one way, there are plenty of other ways - warnings in XE when using a deprecated API - Deprecated API Center, flag dependencies using deprecated code, etc).
We just need someone to propose something that can work in an acceptable manner.
Firefox force-removes old extensions when you upgrade. Some design where old extensions quietly pulled in the legacy modules doesn't seem any better than shipping them by default as they will end up installed everywhere anyway.
The way I see it, breaking API and removing code is like taking out the garbage. When you do it, you stink and nobody is your friend. If you don't do it, everything stinks but it does so a little at a time. It seems to work reasonably well.. Oracle, Sun and Microsoft have been doing it for years.
Not true, Sun/Oracle have not done that for Java. They've always kept backward compat. and taken that seriously. I don't know too much about Microsoft but I can't imagine any development platform breaking users without offering an upgrade path.
That's what I mean, Sun's policy with Java has been to "never take out the garbage" and the latest version is 150MB after unpacking. I've heard from the grapevine that Oracle has (database) code which nobody at the firm knows what it does and nobody dares to touch or remove it. Microsoft has done 3 major rewrites of Windows (95, 2000/NT, Vista) and done an incredible job of maintaining backward compatibility, at a very high expense no doubt. My point is that not taking out the garbage is an option. It's probably not the best but we wouldn't be alone in choosing it.
All I care about is that we have a plan, if we want to remove stuff then lets make it happen, if we want to never remove anything then lets make it a conscious decision. I don't like the idea of having the decision make itself while we put it off.
We all agree we need to find a solution. To summarize, ATM, we all agree about the general strategy, we just haven't found an acceptable implementation yet :)
This sounds unfortunately like "we like to think about it but nobody wants to get smelly". If we want to *not* remove anything then we may have opportunities to improve existing code rather than rewriting it. If we want to actively remove code then we have opportunities to improve the stability and performance by changing execution paths. If we want to talk about removing code but not do it then we don't have any of these opportunities. Caleb
Thanks -Vincent
Caleb
On 05/23/2012 06:09 AM, Paul Libbrecht wrote:
Could they be shipped but deactivated by default? And let the EM activate them? Sounds normal for an EM job though I agree it's an extra work. Making it visible is a good way to encourage the people to upgrade their extensions or make them "visible is old grumps".
paul
Le 23 mai 2012 à 10:34, Thomas Mortagne a écrit :
-1 too, not bundling at least core extensions legacy modules will make EM more or less unusable for many extension older than the current version right now.
On Wed, May 23, 2012 at 9:43 AM, Marius Dumitru Florea <[email protected]> wrote:
On Tue, May 22, 2012 at 5:58 PM, Vincent Massol <[email protected]> wrote:
Hi Caleb,
On May 22, 2012, at 5:00 PM, Caleb James DeLisle wrote:
> Hi, > > I understand we agreed in http://lists.xwiki.org/pipermail/devs/2012-March/050172.html to stop > bundling legacy modules by default. What was not so clear is how we should do this. > > I want to remove the modules from XE and Manager, and document the method of downloading them from > maven.xwiki.org and replacing the existing .jar files with them.
It's not enough IMO. Here's a likely scenario:
* Users will download the version without legacy modules. * Then they'll use the Extension Manager to install extensions from extensions.xwiki.org * The extensions will fail * Users will ditch xwiki since it just doesn't work and the quality is perceived as not good enough.
We need to solve this before we can stop bundling the legacy modules IMO.
> Why: > > #1. Not removing API is obviously unsustainable in the long term. > > #2. Replacing core .jar files has been judged to be beyond the scope of the extension manager. > Whether we want to support overriding classes using extensions as a "function hooking" mechanism is a possible topic for future discussion. > > #3. Replacing .jar files in the .war is not an excessively complex task, we ask users to open the > war file for configuring a database or adding JDBC connectors, cases where there is much less > technical need to require opening the .war file. > > > Here's my +1 to remove it ASAP, for 4.1M2 if we can get the tests passing.
-1 till we solve the question above. I'd rather keep legacy modules than have dissatisfied users.
-1 for the same reason.
Thanks, Marius
Thanks -Vincent
> > Caleb
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, May 23, 2012 at 2:36 PM, Caleb James DeLisle <[email protected]> wrote:
On 05/23/2012 07:43 AM, Vincent Massol wrote:
On May 23, 2012, at 1:25 PM, Caleb James DeLisle wrote:
3 -1's so there is definitely plenty of agreement in this case.
My understanding is that in "Distribute without legacy modules by default" "distribute" means "distribute [enterprise and manager]", which would make this a reversal of the agreement voted upon here: http://lists.xwiki.org/pipermail/devs/2012-April/050386.html
At any rate I am curious as to whether the community wants to ever remove anything. If we want to get to the point of removing things then I want to help, if we don't want to then I will accept it.
- We vote to never remove/break things (except on rare occasions) - However we've also decided to not stink by moving things to Legacy and using aspects ;) - Now the next step is to decide how we make users aware of deprecated stuff (removing from the distribution is one way, there are plenty of other ways - warnings in XE when using a deprecated API - Deprecated API Center, flag dependencies using deprecated code, etc).
We just need someone to propose something that can work in an acceptable manner.
Firefox force-removes old extensions when you upgrade. Some design where old extensions quietly pulled in the legacy modules doesn't seem any better than shipping them by default as they will end up installed everywhere anyway.
The way I see it, breaking API and removing code is like taking out the garbage. When you do it, you stink and nobody is your friend. If you don't do it, everything stinks but it does so a little at a time. It seems to work reasonably well.. Oracle, Sun and Microsoft have been doing it for years.
Not true, Sun/Oracle have not done that for Java. They've always kept backward compat. and taken that seriously. I don't know too much about Microsoft but I can't imagine any development platform breaking users without offering an upgrade path.
That's what I mean, Sun's policy with Java has been to "never take out the garbage" and the latest version is 150MB after unpacking. I've heard from the grapevine that Oracle has (database) code which nobody at the firm knows what it does and nobody dares to touch or remove it. Microsoft has done 3 major rewrites of Windows (95, 2000/NT, Vista) and done an incredible job of maintaining backward compatibility, at a very high expense no doubt.
My point is that not taking out the garbage is an option. It's probably not the best but we wouldn't be alone in choosing it.
All I care about is that we have a plan, if we want to remove stuff then lets make it happen, if we want to never remove anything then lets make it a conscious decision. I don't like the idea of having the decision make itself while we put it off.
We all agree we need to find a solution. To summarize, ATM, we all agree about the general strategy, we just haven't found an acceptable implementation yet :)
This sounds unfortunately like "we like to think about it but nobody wants to get smelly". If we want to *not* remove anything then we may have opportunities to improve existing code rather than rewriting it. If we want to actively remove code then we have opportunities to improve the stability and performance by changing execution paths. If we want to talk about removing code but not do it then we don't have any of these opportunities.
Not deleting something does not force you to use it, we have many things we rewritten in a better way and move to legacy. They are here for any old extension that needs it but at the same time new extensions have the liberty to use new and better API/implementation.
Caleb
Thanks -Vincent
Caleb
On 05/23/2012 06:09 AM, Paul Libbrecht wrote:
Could they be shipped but deactivated by default? And let the EM activate them? Sounds normal for an EM job though I agree it's an extra work. Making it visible is a good way to encourage the people to upgrade their extensions or make them "visible is old grumps".
paul
Le 23 mai 2012 à 10:34, Thomas Mortagne a écrit :
-1 too, not bundling at least core extensions legacy modules will make EM more or less unusable for many extension older than the current version right now.
On Wed, May 23, 2012 at 9:43 AM, Marius Dumitru Florea <[email protected]> wrote:
On Tue, May 22, 2012 at 5:58 PM, Vincent Massol <[email protected]> wrote: > Hi Caleb, > > On May 22, 2012, at 5:00 PM, Caleb James DeLisle wrote: > >> Hi, >> >> I understand we agreed in http://lists.xwiki.org/pipermail/devs/2012-March/050172.html to stop >> bundling legacy modules by default. What was not so clear is how we should do this. >> >> I want to remove the modules from XE and Manager, and document the method of downloading them from >> maven.xwiki.org and replacing the existing .jar files with them. > > It's not enough IMO. Here's a likely scenario: > > * Users will download the version without legacy modules. > * Then they'll use the Extension Manager to install extensions from extensions.xwiki.org > * The extensions will fail > * Users will ditch xwiki since it just doesn't work and the quality is perceived as not good enough. > > We need to solve this before we can stop bundling the legacy modules IMO. > >> Why: >> >> #1. Not removing API is obviously unsustainable in the long term. >> >> #2. Replacing core .jar files has been judged to be beyond the scope of the extension manager. >> Whether we want to support overriding classes using extensions as a "function hooking" mechanism is a possible topic for future discussion. >> >> #3. Replacing .jar files in the .war is not an excessively complex task, we ask users to open the >> war file for configuring a database or adding JDBC connectors, cases where there is much less >> technical need to require opening the .war file. >> >> >> Here's my +1 to remove it ASAP, for 4.1M2 if we can get the tests passing. >
> -1 till we solve the question above. I'd rather keep legacy modules than have dissatisfied users.
-1 for the same reason.
Thanks, Marius
> > Thanks > -Vincent > >> >> Caleb
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 (5)
-
Caleb James DeLisle -
Marius Dumitru Florea -
Paul Libbrecht -
Thomas Mortagne -
Vincent Massol