xwiki-devs March 2016

xwiki-devs@xwiki.org

35 participants
96 discussions

by Eduard Moraru

Hi devs, Today is BFD#96: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 124 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#96 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13601 Thanks and enjoy your bug fixing day! -Eduard

8 years, 6 months

[xwiki-devs] Android XWiki authenticator and contact synchronization - GSOC 2016

by Manish Bisht

Hello Devs, I am Manish Bisht currently in second year perusing B.Tech from SKIT, Jaipur, Rajasthan (India). I am familiar with many languages some of them are HTML, CSS, JavaScript, PHP, C/C++, Java, and I am currently learning Python also. I have created many projects which are hosted on my github account (https://github.com/manishbisht). Also apart from my college hours i have also started my own startup with Run4Offers ( http://www.run4offers.com/) I would love to contribute on this project. So now I want to contact the mentor for the project discussion. How to contact him. Also If i am going right Under this project we have to make one android application to craete a XWiki authenticator and contact synchronization of XWiki users in the Android contacts. And after authenticating the account will be added to the accounts list like Google, Dropbox are added(I have added the snapshot but I got the message need approval from moderator so i have mailed again with same text without snapshot). And then for contact syncronization we have to make syncronization like the WhatsApp does. Can I start working on this project or some other person is working on this. Can I start preparing some of the snapshots that i can attach in my project proposal. Waiting for your replies. Regards, Manish Bisht Founder/CEO Run4Offers.com

8 years, 6 months

[xwiki-devs] [GSoC] 8 hours left to submit your student application!

by Eduard Moraru

Hello interested GSoC students, I`d like to remind you that there are only close to 8 hours left for you to submit your application's final PDF on the GSoC website http://g.co/gsoc XWiki's ideas list is available at http://gsoc.xwiki.org (Reminder) For any questions, don`t hesitate to ask here or on IRC (#xwiki @ freenode). Thanks, Eduard

8 years, 6 months

[xwiki-devs] [Proposal] Improving how we work in xwiki-contrib

by Vincent Massol

Hi all, This mail is about trying to improve how we work in xwiki-contrib and it supersedes the proposal I sent at http://markmail.org/message/qzc7ipiu6lazwbwr Issues with current way of working in xwiki-contrib: * Each project has a lead but this lead is MIA for a lot of extensions and it's a pain to maintain (I'm trying to do it but it's a pain) * It doesn't make much sense to have a lead for an extension but then allowing anyone to commit on it without the lead's approval, nor allowing anyone to release new versions of that project without the lead participating to the discussion. * Right now a committer can release a project using maven but doesn't have permissions to release it in jira nor creating a new version, causing synchronization issues * The XWiki core committers are going to move a lot of non-core extensions to xwiki-contrib but there's no clear lead for a lot of those extensions since they were developed collaboratively and there's no notion of lead in the xwiki github organization. In practice the person from the XWiki core devs to work on a given extension varies over time (that’s how those extensions were built). It's not possible (and not a good idea) to give a long-time leadership to a single person. Proposal: ========= * XWiki Contrib is a community where extensions for XWiki can be developed and maintained together. It's a place that is of interest for people who want to share their sources and work collaboratively with others on them. If the intent is only to make an extension available to users of XWiki then it's enough to publish the binaries on extensions.xwiki.org (and put the souces anywhere they wish, including on the e.x.o page or on their github account if they have one). * XWiki Contrib is defined by the xwiki-contrib github organization * Anyone can request to join this community. This is the main difference with the xwiki github organization where you need to be voted in to become a committer. The main rationale is that making a mistake in the core has more impact than doing this in an extension. The second rationale is that this is an experiment to see if we can have a more vibrant community as a result of being more open, without loosing too much quality. * Once someone joins, he/she has commit access to all repositories in xwiki-contrib (and he/she's also added to a group on jira allowing him to create versions and releasing them.). The goal is to favor cross-pollination. In case this causes problem in the future, we can collaboratively decide to have stricter rules but it's a good experiment/principle to start as open as possible and close only if need be (the wiki principle ;)). So far, after several years of operations, there have been no incident in this way of working for xwiki-contrib that would have required restricting permissions. * In order to simplify participating to any project in xwiki-contrib, the recommended development practices to follow are those found on dev.xwiki.org, i.e. the same as for the xwiki github organization. This prevents the issue that someone who wants to participate to more than 1 project needs to learn several dev practices; they're all the same. Now, these practices are best practices and the intent is that committers try to follow them as much as they can, in their capacity. Other committers reviewing code should be lenient in their comments and sentences like "You must do xxx" should be avoided and instead sentences like "When you have the time, it would be nice if you could...". OTOH, when a committer joins xwiki-contrib, he/she should understand that these best practices exist (and possibly spend some time reading them), and agree about following them as much as he/she can. Obviously anyone is free to discuss an existing rule and propose changing it or dropping it altogether. * Anyone is free to release any project at any time. Recommendation is to send a release "[Proposal]" mail with a few lines explaining the intent to release on such date. If not possible for some constraint (time, neeed to release something else quickly that depends on a given extension, etc) then the release can be performed and some "[ANN]" mail sent later on to announce the release. * Details on best practices (how to write one's pom.xml, how to document extensions on extensions.xwiki.org, etc) are found on contrib.xwiki.org WDYT? Thanks -Vincent

8 years, 6 months

[xwiki-devs] [Proposal] Turn on filesystem attachment store by default in XWiki 8.1

by Vincent Massol

Hi devs, It’s been a very long time that Caleb has implemented fileystem storage and we still see people regularly stuggling to attach largish attachments to their wiki. I think it’s time that we make it the default even if the implementation is still not perfect. Namely here are the opened issue related to filesystem store: https://jira.xwiki.org/issues/?jql=component%20%3D%20%22Storage%20-%20File%… Tha main 2 issues are: - XWiki.DeletedAttachments shows nothing when filesystem attachments are enabled. - FS Attachments does not delete files when a subwiki has been removed I’m proposing for the moment to add a warning to the deleted attachments tab on AllDocs when fs attachment is on. I think the pros outbalances the cons. WDYT? Here’s my +1 Thanks -Vincent

8 years, 6 months

[xwiki-devs] [Proposal] XWiki 8.1 Roadmap

by Vincent Massol

Hi devs, We’ve just released XWiki 8.0 and we now need to think about what to implement in 8.1. I’ve discussed with the XWiki SAS developers and here’s below what we’d like to do in the coming timeframe. Note that several XWiki SAS devs will work on an internal XWiki SAS project during this timeframe and will have less time for XWiki dev for 8.1. * Continue CKEditor work. The goal is to be ready to replace the GWT WYSIWYG by the CKEditor integration before the end of 8.1 and bundle it in 8.1. The default would still be the GWT one but a configuration option would allow to make CK the default + it should be possible to have both editors available for testing. - Marius * Develop an SSO authenticator to authenticate on an XWiki instance based on users located on another XWiki instance (basically if you’re authenticated on XWiki instance 1 then you’d be authenticated on XWiki instance 2). + possibly oAuth authentication - Thomas * Business as usual: Bug Fixing Days every Thursday + polishing of existing features - All * Finish Migration Guide to XWiki 7.4+ + Nested Spaces migrator - Guillaume * Finish work related to the minimal distribution/XWiki flavor - Thomas In addition here’s a list of JIRA we’d like to fix (time permitting): - When leaving the edit mode without saving, notify the user that there are changes he needs to save - XWIKI-6927 - Be able to also restore deleted children pages when restoring a parent nested page - XWIKI-13164 - Create an extension point for the "Content Menu” area - XWIKI-13078 - Bad Image Scaling Quality - XWIKI-7623 - Solr search UI is very slow - XWIKI-12043 - Add a configuration to force EM to always ask when a page is modified instead of merging when possible - XWIKI-12190 @all devs: anything else you’re interested in working on for XWiki 8.1? Thanks -Vincent

8 years, 6 months

[xwiki-devs] [XWiki Day] BFD#95

by Eduard Moraru

Hi devs, Today is BFD#95: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 121 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#95 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13599 Thanks and enjoy your bug fixing day! -Eduard

8 years, 6 months

[xwiki-devs] [Contrib] Request repository for permission macro

by Mohamed Boussaa

Hello devs, I'd like a repository on xwiki-contrib and a Jira project for the permission macro (name of the repo: macro-permission). The Permission macro allow the content to execute based on whether the user has the permission to do so. It is based on this task: http://jira.xwiki.org/browse/XWIKI-12650?filter=10534 Thanks, Mohamed

8 years, 6 months

[xwiki-devs] [Idea] Externalize backward compat checks in a wik page?

by Vincent Massol

Hi devs, I’ve been thinking about how to improve our release process regarding the backward compat checks (we were using clirr for this and now revapi). In short the idea is: * Store the revapi config (containing the list of breakages to ignore) in a wiki page on xwiki.org, associated with a given release note. For example in ReleaseNotes.BackwardCompatibilityForXWiki${xwiki.version.major}${xwiki.version.minor} (using http://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html) * Configure our build to download that json file and store it in target/ for revapi, see https://github.com/revapi/revapi/issues/31#issuecomment-200286810 * Work on making it not fail the build when offline (see https://github.com/revapi/revapi/issues/31#issuecomment-200286810) * Write some groovy script in the release notes template page to automatically generate the “API Breakage” section from the parsed json from ReleaseNotes.BackwardCompatibilityForXWiki${xwiki.version.major}${xwiki.version.minor} WDYT? Thanks -Vincent

8 years, 6 months

[xwiki-devs] [Brainstorming] Display of documents in AllDocs LT in multilingual mode

by Vincent Massol

Hi, This is a brainstorming aimed at fixing: * http://jira.xwiki.org/browse/XWIKI-10384 * http://jira.xwiki.org/browse/XWIKI-12033 In addition I believe we need to support the following use cases: * UC1: (Simple) users should be able to see documents in the currently selected UI language and documents with no translations * UC2: (Advanced) users should be able to see all documents in the wiki (i.e. all translations + all docs with no translations) * UC3: It could be interesting to have an option to limit the translations to the list of configured languages of the wiki ATM the issues is that: * the “currentlanguage” query filter is not implemented properly and returns duplicates (the default language + the translation) * sorting can fail * there’s no way for an advanced users to see all translations in the AllDocs LT Also note that Marius (who’s discovered the problem) as commented at http://jira.xwiki.org/browse/XWIKI-9229 There are several solutions I can imagine Solution 1 ======== The idea is to implement a query filter that returns “a given language + the default language if there’s no translation”. It can be done, see http://jira.xwiki.org/browse/XWIKI-9229?focusedCommentId=90654&page=com.atl… Pros: - Generic solution that would work wherever we use the query manager in the wiki Cons: - it’s “slow”. - It’s also not solving UC2 and UC3. Solution 2 ======== When the wiki is in multilingual mode, add a “Language” column in the LT and display all docs having translations in one of the configured languages of the wiki + all docs with no translations. The user will see duplicates but the “Language” column will indicate clearly that they are different translations. Pros: - This would fix UC3, partially UC2 and partially UC1. Cons: - Not a generic solution; only solves the issue for the AllDocs LT (and the other places where we want to do the same). Solution 3 ======== (initially proposed by Marius) Have a toggle with several states somewhere in the AllDocs UI (could be outside of the LT) to be able to choose different results: * Only docs in the current UI language * Only docs that don’t have translations * All docs * All docs in one of the configured languages of the wiki Note that from a wiki syntax POV, this could be a parameter in the {{document/}} live table. Pros: - This would fix UC2, UC3 and partially UC1. Cons: - Not a generic solution; only solves the issue for the AllDocs LT (and the other places where we want to do the same). Solution 4 ========= Modify the DB schema and add a column in the xwikidocs table to indicate if a doc has translations. This would mean updating it when a new translation is created and when a translation is removed. Pros: - Fast query - Generic solution that will work with any query using the query manager Cons: - Requires a DB update Conclusion ========= Solution 4 seems to be the only real generic solution. WDYT? Any other idea? Thanks -Vincent

8 years, 6 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs March 2016