[xwiki-devs] [VOTE] Stop supporting XWiki Manager
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore. The build is currently broken (because of the XAR organization changes). So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org Here is my non-binding +1. LM
On Sep 11, 2013, at 11:58 AM, "Guillaume \"Louis-Marie\" Delhumeau" <[email protected]> wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
+1, we should do this ASAP since the 5.2M2 release is starting real soon and we should not distribute XEM in 5.2M2. Thanks -Vincent
Note (because Sorin asked an interesting question on IRC): The old use-case of creating subwikis (not workspaces) in a farm is still possible by installing manually the Wiki Manager UI through the Extensions Manager. This is still a temporary solution, because in 5.3, we will really merge wiki-manager with workspace-manager and add the "Users Isolation" option when you create a wiki. 2013/9/11 Vincent Massol <[email protected]>
On Sep 11, 2013, at 11:58 AM, "Guillaume \"Louis-Marie\" Delhumeau" < [email protected]> wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
+1, we should do this ASAP since the 5.2M2 release is starting real soon and we should not distribute XEM in 5.2M2.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 On Wed, Sep 11, 2013 at 11:58 AM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 On Wed, Sep 11, 2013 at 1:54 PM, Thomas Mortagne <[email protected]>wrote:
+1
On Wed, Sep 11, 2013 at 11:58 AM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM _______________________________________________ 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
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
+1 Thanks, Fabio On Wed, Sep 11, 2013 at 11:58 AM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1, only thing I want to mention here is that we'll have to change the documentation from XWiki.org and also maybe on the RN we should put something more visible. On Wed, Sep 11, 2013 at 3:16 PM, Fabio Mancinelli < [email protected]> wrote:
+1
Thanks, Fabio
On Wed, Sep 11, 2013 at 11:58 AM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 Thanks, Marius On Wed, Sep 11, 2013 at 12:58 PM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 Thanks, Caty On Wed, Sep 11, 2013 at 9:34 PM, Marius Dumitru Florea < [email protected]> wrote:
+1
Thanks, Marius
On Wed, Sep 11, 2013 at 12:58 PM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM _______________________________________________ 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 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM
-1. This is very premature, the new workspaces haven't been available for a long enough time to be sure it is a good replacement for XEM. Do workspaces fulfill all the needs of existing XEM users? Does the new implementation offer support for the Farm usage? Is there a clear migration path? Manual or automatic? Is the new wiki management UI going to be at least as easy to use as the old one? What's the learning curve for administrators? If the build is broken, it's easier to fix it than to upset a large userbase. Why do we insist so much on maintaining backwards compatibility for Java APIs that we're almost certain nobody uses, yet we're OK with dropping an entire product without a proven alternative, hoping that in one or two more releases that alternative will actually be fully implemented? -- Sergiu Dumitriu http://purl.org/net/sergiu
Hi Sergiu, On Sep 12, 2013, at 5:11 PM, Sergiu Dumitriu <[email protected]> wrote:
On 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM
-1. This is very premature, the new workspaces haven't been available for a long enough time to be sure it is a good replacement for XEM.
We will never be able to support XEM as it was since we've modified workspaces (we didn't add a new module ;)). Also, since XEM has always been a packaging only it's not a bit deal. You could always install the XEM feature on an XE.
Do workspaces fulfill all the needs of existing XEM users?
yes it's the same thing...
Does the new implementation offer support for the Farm usage?
same as XEM but the UI module is not installed (it was installed in XEM but hidden). We could add it but it's a bad idea since it's misleading. The better solution is what we plan for 5.3 which is to merge the 2 notions.
Is there a clear migration path? Manual or automatic?
automatic, there's a jira issue for making it work in 5.2.
Is the new wiki management UI going to be at least as easy to use as the old one? What's the learning curve for administrators?
it's the same one…
If the build is broken, it's easier to fix it than to upset a large userbase.
No. Again, we modified workspaces so even if continue providing the XEM packaging the changes will be there and if we upset users in XE we will upset them in XEM...
Why do we insist so much on maintaining backwards compatibility for Java APIs that we're almost certain nobody uses, yet we're OK with dropping an entire product without a proven alternative, hoping that in one or two more releases that alternative will actually be fully implemented?
See above. Thanks -Vincent
On 09/12/2013 11:29 AM, Vincent Massol wrote:
Hi Sergiu,
On Sep 12, 2013, at 5:11 PM, Sergiu Dumitriu <[email protected]> wrote:
On 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM
-1. This is very premature, the new workspaces haven't been available for a long enough time to be sure it is a good replacement for XEM.
We will never be able to support XEM as it was since we've modified workspaces (we didn't add a new module ;)).
There once was a thing called wiki-manager, and XEM was using it. Is this no longer true, or why do you say that "workspaces" has changed?
Also, since XEM has always been a packaging only it's not a bit deal. You could always install the XEM feature on an XE.
Do workspaces fulfill all the needs of existing XEM users?
yes it's the same thing...
Does the new implementation offer support for the Farm usage?
same as XEM but the UI module is not installed (it was installed in XEM but hidden). We could add it but it's a bad idea since it's misleading. The better solution is what we plan for 5.3 which is to merge the 2 notions.
Is there a clear migration path? Manual or automatic?
automatic, there's a jira issue for making it work in 5.2.
Is the new wiki management UI going to be at least as easy to use as the old one? What's the learning curve for administrators?
it's the same one…
I don't get it... Things are different, yet they're the same? I've seen a lot of UI changes, name changes, functionality changes, yet nothing actually changed since XEM is Workspaces? Maybe we're talking about different things. I'm not asking if Workspaces packaged as XEM has the same functionality as XEM, I'm asking if the old multiwiki farm manager that has been available in 2.x, 3.x, 4.x and is still used on MyXWiki will still be available.
If the build is broken, it's easier to fix it than to upset a large userbase.
No. Again, we modified workspaces so even if continue providing the XEM packaging the changes will be there and if we upset users in XE we will upset them in XEM...
Why do we insist so much on maintaining backwards compatibility for Java APIs that we're almost certain nobody uses, yet we're OK with dropping an entire product without a proven alternative, hoping that in one or two more releases that alternative will actually be fully implemented?
See above.
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu
On Sep 12, 2013, at 6:02 PM, Sergiu Dumitriu <[email protected]> wrote:
On 09/12/2013 11:29 AM, Vincent Massol wrote:
Hi Sergiu,
On Sep 12, 2013, at 5:11 PM, Sergiu Dumitriu <[email protected]> wrote:
On 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM
-1. This is very premature, the new workspaces haven't been available for a long enough time to be sure it is a good replacement for XEM.
We will never be able to support XEM as it was since we've modified workspaces (we didn't add a new module ;)).
There once was a thing called wiki-manager, and XEM was using it. Is this no longer true, or why do you say that "workspaces" has changed?
It still exists and is made of 2 modules: an API and a UI. the API bundled by default as was the case in XEM. The UI one is not bundled by default in XE.
Also, since XEM has always been a packaging only it's not a bit deal. You could always install the XEM feature on an XE.
Do workspaces fulfill all the needs of existing XEM users?
yes it's the same thing...
Does the new implementation offer support for the Farm usage?
same as XEM but the UI module is not installed (it was installed in XEM but hidden). We could add it but it's a bad idea since it's misleading. The better solution is what we plan for 5.3 which is to merge the 2 notions.
Is there a clear migration path? Manual or automatic?
automatic, there's a jira issue for making it work in 5.2.
Is the new wiki management UI going to be at least as easy to use as the old one? What's the learning curve for administrators?
it's the same one…
I don't get it... Things are different, yet they're the same? I've seen a lot of UI changes, name changes, functionality changes, yet nothing actually changed since XEM is Workspaces?
The platform-workspaces module has changed. This module was bundled in XEM. Now it's bundled in XE too.
Maybe we're talking about different things. I'm not asking if Workspaces packaged as XEM has the same functionality as XEM, I'm asking if the old multiwiki farm manager that has been available in 2.x, 3.x, 4.x and is still used on MyXWiki will still be available.
Yes it's there and not touched at all (it's wiki-manager-api and wiki-manager-ui FTR). Thanks -Vincent
If the build is broken, it's easier to fix it than to upset a large userbase.
No. Again, we modified workspaces so even if continue providing the XEM packaging the changes will be there and if we upset users in XE we will upset them in XEM...
Why do we insist so much on maintaining backwards compatibility for Java APIs that we're almost certain nobody uses, yet we're OK with dropping an entire product without a proven alternative, hoping that in one or two more releases that alternative will actually be fully implemented?
See above.
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Sep 12, 2013 at 5:11 PM, Sergiu Dumitriu <[email protected]> wrote:
On 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM
-1. This is very premature, the new workspaces haven't been available for a long enough time to be sure it is a good replacement for XEM.
Do workspaces fulfill all the needs of existing XEM users?
XEM became a workspaces manager in 3.3 (see http://jira.xwiki.org/browse/XEM-202) so there is nothing new here. The only difference between the new XE and XEM is that wiki manager UI is not included while it was hidden in XEM so it's not a big change for users since it's super easy to install with Extension Manager. XEM is and always been pretty much only a set of pom.xml files with dependencies and not much more than a home page. Guillaume moved Workspaces from XEM to XE making XEM pretty much useless now.
Does the new implementation offer support for the Farm usage?
You can install Wiki Manager UI using Extension Manager.
Is there a clear migration path? Manual or automatic?
Is the new wiki management UI going to be at least as easy to use as the old one? What's the learning curve for administrators?
If the build is broken, it's easier to fix it than to upset a large userbase. Why do we insist so much on maintaining backwards compatibility for Java APIs that we're almost certain nobody uses, yet we're OK with dropping an entire product without a proven alternative, hoping that in one or two more releases that alternative will actually be fully implemented?
The point here is that the alternative is XE. We don't remove XEM because the build is broken... It simply does not worth the effort to keep it anymore since XE expose the same features.
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 09/13/2013 08:51 AM, Thomas Mortagne wrote:
On Thu, Sep 12, 2013 at 5:11 PM, Sergiu Dumitriu <[email protected]> wrote:
On 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM
-1. This is very premature, the new workspaces haven't been available for a long enough time to be sure it is a good replacement for XEM.
Do workspaces fulfill all the needs of existing XEM users?
XEM became a workspaces manager in 3.3 (see http://jira.xwiki.org/browse/XEM-202) so there is nothing new here. The only difference between the new XE and XEM is that wiki manager UI is not included while it was hidden in XEM so it's not a big change for users since it's super easy to install with Extension Manager.
XEM is and always been pretty much only a set of pom.xml files with dependencies and not much more than a home page. Guillaume moved Workspaces from XEM to XE making XEM pretty much useless now.
Does the new implementation offer support for the Farm usage?
You can install Wiki Manager UI using Extension Manager.
Is there a clear migration path? Manual or automatic?
Is the new wiki management UI going to be at least as easy to use as the old one? What's the learning curve for administrators?
If the build is broken, it's easier to fix it than to upset a large userbase. Why do we insist so much on maintaining backwards compatibility for Java APIs that we're almost certain nobody uses, yet we're OK with dropping an entire product without a proven alternative, hoping that in one or two more releases that alternative will actually be fully implemented?
The point here is that the alternative is XE. We don't remove XEM because the build is broken... It simply does not worth the effort to keep it anymore since XE expose the same features.
Given that as a downstream user I don't really use multiwikis in any way, this doesn't affect me at all. So +1, less code is always better. One product less means less confusion for users. My main complaint was about the backwards compatibility rule that's not being followed. -- Sergiu Dumitriu http://purl.org/net/sergiu
Almost everybody has voted so I think this proposal is approved. 2013/9/13 Sergiu Dumitriu <[email protected]>
On 09/13/2013 08:51 AM, Thomas Mortagne wrote:
On Thu, Sep 12, 2013 at 5:11 PM, Sergiu Dumitriu <[email protected]> wrote:
On 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM
-1. This is very premature, the new workspaces haven't been available for a long enough time to be sure it is a good replacement for XEM.
Do workspaces fulfill all the needs of existing XEM users?
XEM became a workspaces manager in 3.3 (see http://jira.xwiki.org/browse/XEM-202) so there is nothing new here. The only difference between the new XE and XEM is that wiki manager UI is not included while it was hidden in XEM so it's not a big change for users since it's super easy to install with Extension Manager.
XEM is and always been pretty much only a set of pom.xml files with dependencies and not much more than a home page. Guillaume moved Workspaces from XEM to XE making XEM pretty much useless now.
Does the new implementation offer support for the Farm usage?
You can install Wiki Manager UI using Extension Manager.
Is there a clear migration path? Manual or automatic?
Is the new wiki management UI going to be at least as easy to use as the old one? What's the learning curve for administrators?
If the build is broken, it's easier to fix it than to upset a large userbase. Why do we insist so much on maintaining backwards compatibility for Java APIs that we're almost certain nobody uses, yet we're OK with dropping an entire product without a proven alternative, hoping that in one or two more releases that alternative will actually be fully implemented?
The point here is that the alternative is XE. We don't remove XEM because the build is broken... It simply does not worth the effort to keep it anymore since XE expose the same features.
Given that as a downstream user I don't really use multiwikis in any way, this doesn't affect me at all. So +1, less code is always better. One product less means less confusion for users.
My main complaint was about the backwards compatibility rule that's not being followed. -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 Thanks, Eduard On Thu, Sep 19, 2013 at 4:35 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Almost everybody has voted so I think this proposal is approved.
2013/9/13 Sergiu Dumitriu <[email protected]>
On 09/13/2013 08:51 AM, Thomas Mortagne wrote:
On Thu, Sep 12, 2013 at 5:11 PM, Sergiu Dumitriu <[email protected]> wrote:
On 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM
-1. This is very premature, the new workspaces haven't been available for a long enough time to be sure it is a good replacement for XEM.
Do workspaces fulfill all the needs of existing XEM users?
XEM became a workspaces manager in 3.3 (see http://jira.xwiki.org/browse/XEM-202) so there is nothing new here. The only difference between the new XE and XEM is that wiki manager UI is not included while it was hidden in XEM so it's not a big change for users since it's super easy to install with Extension Manager.
XEM is and always been pretty much only a set of pom.xml files with dependencies and not much more than a home page. Guillaume moved Workspaces from XEM to XE making XEM pretty much useless now.
Does the new implementation offer support for the Farm usage?
You can install Wiki Manager UI using Extension Manager.
Is there a clear migration path? Manual or automatic?
Is the new wiki management UI going to be at least as easy to use as
the
old one? What's the learning curve for administrators?
If the build is broken, it's easier to fix it than to upset a large userbase. Why do we insist so much on maintaining backwards compatibility for Java APIs that we're almost certain nobody uses, yet we're OK with dropping an entire product without a proven alternative, hoping that in one or two more releases that alternative will actually be fully implemented?
The point here is that the alternative is XE. We don't remove XEM because the build is broken... It simply does not worth the effort to keep it anymore since XE expose the same features.
Given that as a downstream user I don't really use multiwikis in any way, this doesn't affect me at all. So +1, less code is always better. One product less means less confusion for users.
My main complaint was about the backwards compatibility rule that's not being followed. -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
- move the github repo to xwiki-contrib/retired
I guess you mean "move the github repo to xwiki-contrib" because merging XEM and retired repository would be a pain (a not even sure it would work fully). I prefer to just move the repo to contrib and indicate it's retired like we did for other modules. On Thu, Sep 19, 2013 at 4:32 PM, Eduard Moraru <[email protected]> wrote:
+1
Thanks, Eduard
On Thu, Sep 19, 2013 at 4:35 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Almost everybody has voted so I think this proposal is approved.
2013/9/13 Sergiu Dumitriu <[email protected]>
On 09/13/2013 08:51 AM, Thomas Mortagne wrote:
On Thu, Sep 12, 2013 at 5:11 PM, Sergiu Dumitriu <[email protected]> wrote:
On 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote:
Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does not make any sense to release XWiki Manager (XEM) anymore.
The build is currently broken (because of the XAR organization changes).
So I propose to remove XWiki Manager: - stop releasing it - move the github repo to xwiki-contrib/retired - update manager.xwiki.org to explain the changes in XWiki 5.2. - move the manager jira to the retired category - remove the build in ci.xwiki.org
Here is my non-binding +1.
LM
-1. This is very premature, the new workspaces haven't been available for a long enough time to be sure it is a good replacement for XEM.
Do workspaces fulfill all the needs of existing XEM users?
XEM became a workspaces manager in 3.3 (see http://jira.xwiki.org/browse/XEM-202) so there is nothing new here. The only difference between the new XE and XEM is that wiki manager UI is not included while it was hidden in XEM so it's not a big change for users since it's super easy to install with Extension Manager.
XEM is and always been pretty much only a set of pom.xml files with dependencies and not much more than a home page. Guillaume moved Workspaces from XEM to XE making XEM pretty much useless now.
Does the new implementation offer support for the Farm usage?
You can install Wiki Manager UI using Extension Manager.
Is there a clear migration path? Manual or automatic?
Is the new wiki management UI going to be at least as easy to use as
the
old one? What's the learning curve for administrators?
If the build is broken, it's easier to fix it than to upset a large userbase. Why do we insist so much on maintaining backwards compatibility for Java APIs that we're almost certain nobody uses, yet we're OK with dropping an entire product without a proven alternative, hoping that in one or two more releases that alternative will actually be fully implemented?
The point here is that the alternative is XE. We don't remove XEM because the build is broken... It simply does not worth the effort to keep it anymore since XE expose the same features.
Given that as a downstream user I don't really use multiwikis in any way, this doesn't affect me at all. So +1, less code is always better. One product less means less confusion for users.
My main complaint was about the backwards compatibility rule that's not being followed. -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Sep 19, 2013, at 4:58 PM, Thomas Mortagne <[email protected]> wrote:
- move the github repo to xwiki-contrib/retired
I guess you mean "move the github repo to xwiki-contrib" because merging XEM and retired repository would be a pain (a not even sure it would work fully). I prefer to just move the repo to contrib and indicate it's retired like we did for other modules.
Yes I agree. We'll just need a README.md to let the users know it's not active anymore. We need to decide on a rule for retired project (not sure we agreed although we discussed it). I also much prefer keeping each extension in its own repo and mention in a README.md about its status. Thanks -Vincent
On Thu, Sep 19, 2013 at 4:32 PM, Eduard Moraru <[email protected]> wrote:
+1
Thanks, Eduard
On Thu, Sep 19, 2013 at 4:35 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Almost everybody has voted so I think this proposal is approved.
2013/9/13 Sergiu Dumitriu <[email protected]>
On 09/13/2013 08:51 AM, Thomas Mortagne wrote:
On Thu, Sep 12, 2013 at 5:11 PM, Sergiu Dumitriu <[email protected]> wrote:
On 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote: > Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does > not make any sense to release XWiki Manager (XEM) anymore. > > The build is currently broken (because of the XAR organization changes). > > So I propose to remove XWiki Manager: > - stop releasing it > - move the github repo to xwiki-contrib/retired > - update manager.xwiki.org to explain the changes in XWiki 5.2. > - move the manager jira to the retired category > - remove the build in ci.xwiki.org > > Here is my non-binding +1. > > LM
-1. This is very premature, the new workspaces haven't been available for a long enough time to be sure it is a good replacement for XEM.
Do workspaces fulfill all the needs of existing XEM users?
XEM became a workspaces manager in 3.3 (see http://jira.xwiki.org/browse/XEM-202) so there is nothing new here. The only difference between the new XE and XEM is that wiki manager UI is not included while it was hidden in XEM so it's not a big change for users since it's super easy to install with Extension Manager.
XEM is and always been pretty much only a set of pom.xml files with dependencies and not much more than a home page. Guillaume moved Workspaces from XEM to XE making XEM pretty much useless now.
Does the new implementation offer support for the Farm usage?
You can install Wiki Manager UI using Extension Manager.
Is there a clear migration path? Manual or automatic?
Is the new wiki management UI going to be at least as easy to use as
the
old one? What's the learning curve for administrators?
If the build is broken, it's easier to fix it than to upset a large userbase. Why do we insist so much on maintaining backwards compatibility for Java APIs that we're almost certain nobody uses, yet we're OK with dropping an entire product without a proven alternative, hoping that in one or two more releases that alternative will actually be fully implemented?
The point here is that the alternative is XE. We don't remove XEM because the build is broken... It simply does not worth the effort to keep it anymore since XE expose the same features.
Given that as a downstream user I don't really use multiwikis in any way, this doesn't affect me at all. So +1, less code is always better. One product less means less confusion for users.
My main complaint was about the backwards compatibility rule that's not being followed. -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Since XE 5.2 has been released I just moved XEM to xwiki-contrib with a README. On Thu, Sep 19, 2013 at 5:08 PM, Vincent Massol <[email protected]> wrote:
On Sep 19, 2013, at 4:58 PM, Thomas Mortagne <[email protected]> wrote:
- move the github repo to xwiki-contrib/retired
I guess you mean "move the github repo to xwiki-contrib" because merging XEM and retired repository would be a pain (a not even sure it would work fully). I prefer to just move the repo to contrib and indicate it's retired like we did for other modules.
Yes I agree. We'll just need a README.md to let the users know it's not active anymore.
We need to decide on a rule for retired project (not sure we agreed although we discussed it). I also much prefer keeping each extension in its own repo and mention in a README.md about its status.
Thanks -Vincent
On Thu, Sep 19, 2013 at 4:32 PM, Eduard Moraru <[email protected]> wrote:
+1
Thanks, Eduard
On Thu, Sep 19, 2013 at 4:35 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Almost everybody has voted so I think this proposal is approved.
2013/9/13 Sergiu Dumitriu <[email protected]>
On 09/13/2013 08:51 AM, Thomas Mortagne wrote:
On Thu, Sep 12, 2013 at 5:11 PM, Sergiu Dumitriu <[email protected]> wrote: > On 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote: >> Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does >> not make any sense to release XWiki Manager (XEM) anymore. >> >> The build is currently broken (because of the XAR organization changes). >> >> So I propose to remove XWiki Manager: >> - stop releasing it >> - move the github repo to xwiki-contrib/retired >> - update manager.xwiki.org to explain the changes in XWiki 5.2. >> - move the manager jira to the retired category >> - remove the build in ci.xwiki.org >> >> Here is my non-binding +1. >> >> LM > > -1. This is very premature, the new workspaces haven't been available > for a long enough time to be sure it is a good replacement for XEM. > > Do workspaces fulfill all the needs of existing XEM users?
XEM became a workspaces manager in 3.3 (see http://jira.xwiki.org/browse/XEM-202) so there is nothing new here. The only difference between the new XE and XEM is that wiki manager UI is not included while it was hidden in XEM so it's not a big change for users since it's super easy to install with Extension Manager.
XEM is and always been pretty much only a set of pom.xml files with dependencies and not much more than a home page. Guillaume moved Workspaces from XEM to XE making XEM pretty much useless now.
> > Does the new implementation offer support for the Farm usage?
You can install Wiki Manager UI using Extension Manager.
> > Is there a clear migration path? Manual or automatic? > > Is the new wiki management UI going to be at least as easy to use as the > old one? What's the learning curve for administrators? > > > If the build is broken, it's easier to fix it than to upset a large > userbase. Why do we insist so much on maintaining backwards > compatibility for Java APIs that we're almost certain nobody uses, yet > we're OK with dropping an entire product without a proven alternative, > hoping that in one or two more releases that alternative will actually > be fully implemented?
The point here is that the alternative is XE. We don't remove XEM because the build is broken... It simply does not worth the effort to keep it anymore since XE expose the same features.
Given that as a downstream user I don't really use multiwikis in any way, this doesn't affect me at all. So +1, less code is always better. One product less means less confusion for users.
My main complaint was about the backwards compatibility rule that's not being followed. -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- 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
-- Thomas Mortagne
And move the jira project to retired projects category. On Tue, Oct 8, 2013 at 9:20 AM, Thomas Mortagne <[email protected]> wrote:
Since XE 5.2 has been released I just moved XEM to xwiki-contrib with a README.
On Thu, Sep 19, 2013 at 5:08 PM, Vincent Massol <[email protected]> wrote:
On Sep 19, 2013, at 4:58 PM, Thomas Mortagne <[email protected]> wrote:
- move the github repo to xwiki-contrib/retired
I guess you mean "move the github repo to xwiki-contrib" because merging XEM and retired repository would be a pain (a not even sure it would work fully). I prefer to just move the repo to contrib and indicate it's retired like we did for other modules.
Yes I agree. We'll just need a README.md to let the users know it's not active anymore.
We need to decide on a rule for retired project (not sure we agreed although we discussed it). I also much prefer keeping each extension in its own repo and mention in a README.md about its status.
Thanks -Vincent
On Thu, Sep 19, 2013 at 4:32 PM, Eduard Moraru <[email protected]> wrote:
+1
Thanks, Eduard
On Thu, Sep 19, 2013 at 4:35 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Almost everybody has voted so I think this proposal is approved.
2013/9/13 Sergiu Dumitriu <[email protected]>
On 09/13/2013 08:51 AM, Thomas Mortagne wrote: > On Thu, Sep 12, 2013 at 5:11 PM, Sergiu Dumitriu <[email protected]> wrote: >> On 09/11/2013 05:58 AM, Guillaume "Louis-Marie" Delhumeau wrote: >>> Since Enterprise embeds Workspaces by default since 5.2-m2, I think it does >>> not make any sense to release XWiki Manager (XEM) anymore. >>> >>> The build is currently broken (because of the XAR organization changes). >>> >>> So I propose to remove XWiki Manager: >>> - stop releasing it >>> - move the github repo to xwiki-contrib/retired >>> - update manager.xwiki.org to explain the changes in XWiki 5.2. >>> - move the manager jira to the retired category >>> - remove the build in ci.xwiki.org >>> >>> Here is my non-binding +1. >>> >>> LM >> >> -1. This is very premature, the new workspaces haven't been available >> for a long enough time to be sure it is a good replacement for XEM. >> >> Do workspaces fulfill all the needs of existing XEM users? > > XEM became a workspaces manager in 3.3 (see > http://jira.xwiki.org/browse/XEM-202) so there is nothing new here. > The only difference between the new XE and XEM is that wiki manager UI > is not included while it was hidden in XEM so it's not a big change > for users since it's super easy to install with Extension Manager. > > XEM is and always been pretty much only a set of pom.xml files with > dependencies and not much more than a home page. Guillaume moved > Workspaces from XEM to XE making XEM pretty much useless now. > >> >> Does the new implementation offer support for the Farm usage? > > You can install Wiki Manager UI using Extension Manager. > >> >> Is there a clear migration path? Manual or automatic? >> >> Is the new wiki management UI going to be at least as easy to use as the >> old one? What's the learning curve for administrators? >> >> >> If the build is broken, it's easier to fix it than to upset a large >> userbase. Why do we insist so much on maintaining backwards >> compatibility for Java APIs that we're almost certain nobody uses, yet >> we're OK with dropping an entire product without a proven alternative, >> hoping that in one or two more releases that alternative will actually >> be fully implemented? > > The point here is that the alternative is XE. We don't remove XEM > because the build is broken... It simply does not worth the effort to > keep it anymore since XE expose the same features.
Given that as a downstream user I don't really use multiwikis in any way, this doesn't affect me at all. So +1, less code is always better. One product less means less confusion for users.
My main complaint was about the backwards compatibility rule that's not being followed. -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- 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
-- Thomas Mortagne
-- Thomas Mortagne
participants (10)
-
Denis Gervalle -
Ecaterina Moraru (Valica) -
Eduard Moraru -
Fabio Mancinelli -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Sergiu Dumitriu -
Sorin Burjan -
Thomas Mortagne -
Vincent Massol