Re: [xwiki-devs] [VOTE] Move OSCache based cache module to contrib
+1 2015-07-09 18:08 GMT+02:00 Thomas Mortagne thomas.morta...@xwiki.com: Hi devs, We never used OSCache based cache module in years and we never upgrade OSCache dependency. It was mostly created for retro compatibility when we moved to JBoss Cache and to have more that one implementation of the API to do something generic enough but we passed first API design period since a long time now... Here is my +1 -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Guillaume Delhumeau (gdelhum...@xwiki.com) Research Development Engineer at XWiki SAS Committer on the XWiki.org project ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [VOTE] Move OSCache based cache module to contrib
+0 Thanks, Marius On Jul 9, 2015 19:08, Thomas Mortagne thomas.morta...@xwiki.com wrote: Hi devs, We never used OSCache based cache module in years and we never upgrade OSCache dependency. It was mostly created for retro compatibility when we moved to JBoss Cache and to have more that one implementation of the API to do something generic enough but we passed first API design period since a long time now... Here is my +1 -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] [VOTE] Move OSCache based cache module to contrib
Hi devs, We never used OSCache based cache module in years and we never upgrade OSCache dependency. It was mostly created for retro compatibility when we moved to JBoss Cache and to have more that one implementation of the API to do something generic enough but we passed first API design period since a long time now... Here is my +1 -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Iteration][UX] Nested: Tree Location
Hello, Thanks for your effort, Caty! - Solution1: I think in order to see the tree, there are required a minimum number of clicks and this solution clearly doesn’t cover this condition - Solution2: it seems a bit hidden, IMO and also too many clicks, as Sol1 - Solution3: is a very good idea, but is not sufficient and also a bit hidden - Solution4: is too crowded, IMO a breadcrumb should be as simpler as it can be - Solution5: this is the best solution from my point of view, because it also preserves the old breadcrumb and it adds a new element, with a “home” icon which I think is intuitive enough - Solution6: same as Sol3 - really nice to have, but not sufficient As a conclusion, my choice will be a combination between 3 and 5, or 5 and 6. Thanks, Gabriela ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Iteration][UX] Nested: Tree Location
On 9 Jul 2015 at 12:24:50, Guillaume Louis-Marie Delhumeau (gdelhum...@xwiki.com(mailto:gdelhum...@xwiki.com)) wrote: 2015-07-09 12:11 GMT+02:00 vinc...@massol.net : Hi Caty, Thanks for this design page! On 9 Jul 2015 at 11:55:23, Ecaterina Moraru (Valica) (vali...@gmail.com (mailto:vali...@gmail.com)) wrote: Hi devs, By default our Tree is localized in AllDocs. This iteration investigates additional ways to access the current's page position in the hierarchy. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedTreeLocation * I don’t like sol2 because depending the usage done for the wiki, you won’t always want to display a nav panel. So this is an adhoc solution and not a generic one. But look at the top menu in this image. On the right, there is a new menu where you can chose if you want to display the standard app bar or the tree. It is not very obvious and the fact that you did not even see it proves that it is not very intuitive. Indeed, I missed it. Still the AppBar on the left is also only for some flavors and not for all so it cannot be a generic solution. We already have a Navigation Panel (I hope it’s using the new Tree but I don’t recall and if not then it should) and admins can decide to use it where they want. We could have it for some flavors where it makes sense, for example for the documentation flavor but I think we need a more generic solution and sol5/sol6 are better in this regards. Thanks -Vincent * I don’t like sol3 too much (even though it’s interesting) because I find it too hidden away for the users and navigation is a key feature * sol1 is not optimal since it requires 2 clicks and you navigate away from your current page (if you want to cancel the nav it’s not nice). It could be implemented easily though if we want to have something quickly while waiting for a better solution * I like sol6 very much and we should have it but it’s not enough IMO * Sol4 and 5 are very nice IMO So overall my preference goes to Sol4 or 5 (and sol6 done in addition). Thanks a lot -Vincent Thanks, Caty ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] [Proposal] Releasing a contrib project - Guidelines
Hi devs, I’d like to propose to add some guidelines to contrib.xwiki.org when someone wants to release a project, especially when that person is not the project lead. * The person wanting to do the release should contact the project lead, preferable either through IRC or the mailing list to mention its intent to perform a new release. ** This allows anyone who also want to have some issue fixed be able to do so in the same release for example. ** Usually that person will not have the permission to create a version in JIRA for that project and thus he/she’ll need the Project Lead’s help for that WDYT? Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Proposal] Releasing a contrib project - Guidelines
+1 Additionally, if the Project Lead is unavailable, the release could still be performed with the help of a committer, after the release intent has been announced on the mailinglists. Thanks, Caty On Thu, Jul 9, 2015 at 12:11 PM, vinc...@massol.net vinc...@massol.net wrote: Hi devs, I’d like to propose to add some guidelines to contrib.xwiki.org when someone wants to release a project, especially when that person is not the project lead. * The person wanting to do the release should contact the project lead, preferable either through IRC or the mailing list to mention its intent to perform a new release. ** This allows anyone who also want to have some issue fixed be able to do so in the same release for example. ** Usually that person will not have the permission to create a version in JIRA for that project and thus he/she’ll need the Project Lead’s help for that WDYT? Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] [Iteration][UX] Nested: Tree Location
Hi devs, By default our Tree is localized in AllDocs. This iteration investigates additional ways to access the current's page position in the hierarchy. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedTreeLocation Thanks, Caty ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Iteration][UX] Nested: Tree Location
Good initiative. I like the combination of sol 3, 5 and 6. Sol 1: too much clicks and hidden in the crowd Sol 2: nice one but it does not have my preference (a bit complicated maybe) Sol 3: not sufficient but I believe this information panel should have this tree anyway Sol 4: too much clutter Sol 5: my favourite. Easy to use and find, but easily to hide too. Sol 6: not sufficient but I believe this popup should have this tree anyway Thanks, Guillaume 2015-07-09 11:55 GMT+02:00 Ecaterina Moraru (Valica) vali...@gmail.com: Hi devs, By default our Tree is localized in AllDocs. This iteration investigates additional ways to access the current's page position in the hierarchy. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedTreeLocation Thanks, Caty ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Guillaume Delhumeau (gdelhum...@xwiki.com) Research Development Engineer at XWiki SAS Committer on the XWiki.org project ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Iteration][UX] Nested: Tree Location
Hi Caty, Thanks for this design page! On 9 Jul 2015 at 11:55:23, Ecaterina Moraru (Valica) (vali...@gmail.com(mailto:vali...@gmail.com)) wrote: Hi devs, By default our Tree is localized in AllDocs. This iteration investigates additional ways to access the current's page position in the hierarchy. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedTreeLocation * I don’t like sol2 because depending the usage done for the wiki, you won’t always want to display a nav panel. So this is an adhoc solution and not a generic one. * I don’t like sol3 too much (even though it’s interesting) because I find it too hidden away for the users and navigation is a key feature * sol1 is not optimal since it requires 2 clicks and you navigate away from your current page (if you want to cancel the nav it’s not nice). It could be implemented easily though if we want to have something quickly while waiting for a better solution * I like sol6 very much and we should have it but it’s not enough IMO * Sol4 and 5 are very nice IMO So overall my preference goes to Sol4 or 5 (and sol6 done in addition). Thanks a lot -Vincent Thanks, Caty ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Iteration][UX] Nested: Tree Location
On 9 Jul 2015 at 12:08:16, Guillaume Louis-Marie Delhumeau (gdelhum...@xwiki.com(mailto:gdelhum...@xwiki.com)) wrote: Good initiative. I like the combination of sol 3, 5 and 6. Sol 1: too much clicks and hidden in the crowd Sol 2: nice one but it does not have my preference (a bit complicated maybe) Sol 3: not sufficient but I believe this information panel should have this tree anyway Sol 4: too much clutter Actually this a wireframe. Visually you wouldn’t see any difference and it’s only when you click on the breadcrumb item that you’d see the dropdown. But that raises the issue with mobile (same issue as we had with the top menu) so indeed we’re a bit stuck. Sol 5: my favourite. Easy to use and find, but easily to hide too. Me too. Thanks -Vincent Sol 6: not sufficient but I believe this popup should have this tree anyway Thanks, Guillaume 2015-07-09 11:55 GMT+02:00 Ecaterina Moraru (Valica) : Hi devs, By default our Tree is localized in AllDocs. This iteration investigates additional ways to access the current's page position in the hierarchy. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedTreeLocation Thanks, Caty ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Iteration][UX] Nested: Tree Location
2015-07-09 12:11 GMT+02:00 vinc...@massol.net vinc...@massol.net: Hi Caty, Thanks for this design page! On 9 Jul 2015 at 11:55:23, Ecaterina Moraru (Valica) (vali...@gmail.com (mailto:vali...@gmail.com)) wrote: Hi devs, By default our Tree is localized in AllDocs. This iteration investigates additional ways to access the current's page position in the hierarchy. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedTreeLocation * I don’t like sol2 because depending the usage done for the wiki, you won’t always want to display a nav panel. So this is an adhoc solution and not a generic one. But look at the top menu in this image. On the right, there is a new menu where you can chose if you want to display the standard app bar or the tree. It is not very obvious and the fact that you did not even see it proves that it is not very intuitive. * I don’t like sol3 too much (even though it’s interesting) because I find it too hidden away for the users and navigation is a key feature * sol1 is not optimal since it requires 2 clicks and you navigate away from your current page (if you want to cancel the nav it’s not nice). It could be implemented easily though if we want to have something quickly while waiting for a better solution * I like sol6 very much and we should have it but it’s not enough IMO * Sol4 and 5 are very nice IMO So overall my preference goes to Sol4 or 5 (and sol6 done in addition). Thanks a lot -Vincent Thanks, Caty ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Guillaume Delhumeau (gdelhum...@xwiki.com) Research Development Engineer at XWiki SAS Committer on the XWiki.org project ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [VOTE] Move OSCache based cache module to contrib
+1, besides the project has been retired in 2011. On 07/09/2015 12:08 PM, Thomas Mortagne wrote: Hi devs, We never used OSCache based cache module in years and we never upgrade OSCache dependency. It was mostly created for retro compatibility when we moved to JBoss Cache and to have more that one implementation of the API to do something generic enough but we passed first API design period since a long time now... Here is my +1 -- Sergiu Dumitriu http://purl.org/net/sergiu ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
