xwiki-devs June 2013

xwiki-devs@xwiki.org

24 participants
64 discussions

[xwiki-devs] [proposal] Process to handle Pull Requests

by Ludovic Dubost

Hi devs, I don't think there is currently a process that is in place to handle pull requests and I have the feeling that the way there are handled today is a bit random. There are usually comments sent out on each pull request but sometimes it seems that some pull requests are going in sleep mode and it's not clear who is in charge. I would like to suggest that a process is put in place where it's clear who is responsible for a pull request and a status is given to the contributors that propose that pull request. Something like: Assigned developer: XXXX Status: New -> new pull request, not yet assigned Assigned -> assigned to a developer, he is in charge of reviewing the pull request and ask for modifications or accept it. The developer can auto assign it to himself. If nobody does, we need to decide how they will be taken into account. ModificationsRequired -> for now rejected with comments. Contributor needs to apply comments and then change back to Assigned for further evaluation VoteRequired -> there are no more comments, but a vote is required as the changes to XWiki core are important WaitingFinalAuthorization -> optional step for complex patches where a additional authorization would be required (need to define who would be the persons that give the authorization) WaitingApplication -> there are no more comments and no changes or vote required. The pull request can be applied and is waiting for a developer to apply it Abandoned -> contributors is abandoning the pull request (cannot do the changes, no more time, etc..) Rejected -> pull request is rejected (quality not enough, etc..) Applied -> pull request is applied What do you think ? Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

5 years, 7 months

[xwiki-devs] Convention for class property hints ?

by Jerome Velociter

Hello, Right now class property hints are not supported right in the core of XWiki (though it's been mentioned as a possible future item of the roadmap for AWM, see http://markmail.org/message/ltuphlj7bnnso2yb ). Once this will be implemented, it will rely on i18n message keys so that hints are localizables (same strategy as for class property pretty names) I'd like to start the discussion and see if we can agree on a convention that would be used in the future when this module is implemented. The reason for this is I'm starting to work on a LDAP admin UI, and I find that their field pretty names are not self-explanatory. It's not a matter of expression, it's just the fact that what they describe needs more explanation than what the pretty name can offer). In this light, I'm planning on displaying such longer hints in this admin section. Right now the format for a pretty name is : Space.Class_property=Pretty name The format for a hint could be something like : Space.Class_property.xHint=Hint This would need escaping rules I think, since I believe "property.xHint" is a valid property name Note that I use "xHint" and not "hint" to be consistent with the form standards class names. This can be discussed though. WDYT ? Do you have other ideas ? Jerome. -- Jérôme Velociter Winesquare http://www.winesquare.net/

8 years, 5 months

[xwiki-devs] [Idea] Sponsoring issues

by Vincent Massol

Hi devs, WDYT of doing like Jenkins is doing and adding a "Sponsor this issue" button on JIRA? For example: https://issues.jenkins-ci.org/browse/JENKINS-9030 When you click it redirects to http://www.freedomsponsors.org/core/login/?next=/core/issue/sponsor%3Ftrack… You can check http://www.freedomsponsors.org/ It could be interesting to try it and see how it goes. WDYT? Thanks -Vincent

8 years, 10 months

[xwiki-devs] [UX][Consistency][Vote] "Page" vs. "Document" consistent naming

by Ecaterina Moraru (Valica)

Hi, We are using mixed naming when referring to a document/page, not only on different pages, but also in the same context (Rename step for example). There is also an issue referring to this problem XWIKI-5401<http://jira.xwiki.org/jira/browse/XWIKI-5401>and we need to find an answer in order to move forward consistency. So the question is which version we prefer: "Page" or "Document" ? I'm voting +1 for "Page". "Page" is more used IMO, especially in the "Space"/"Page" context. "Page" is more general than "Document" and better fitted for a platform that encapsulates all kind of content (not just documents). Please cast your vote. Thanks, Caty

9 years, 3 months

[xwiki-devs] [Proposal] Object addition/removal/update shouldn't change content author

by Vincent Massol

Hi, According to the javadoc in XWikiDocument: /** * The last user that has changed the document's content (ie not object, attachments). The Content author is only * changed when the document content changes. Note that Content Author is used to check programming rights on a * document and this is the reason we need to know the last author who's modified the content since programming * rights depend on this. */ private DocumentReference contentAuthorReference; This means that objectadd or objectremove actions shouldn't change the content author as they do now. I'm proposing that we fix this. Do you see any issue? Thanks -Vincent

9 years, 6 months

[xwiki-devs] [Proposal] Split XE pages into platform modules

by Vincent Massol

Hi devs, Here's a proposal to move pages currently located in XE into platform modules: * ColorThemes/*.xml --> xwiki-platform-colorthemes * Main/Activity.xml --> xwiki-platform-activitystream-ui (move current xwiki-platform-activitytream into xwiki-platform-activitystream-api) * Main/AllDocs.xml (and XWiki.Tableview, XWiki.Treeview, XWiki.OrphanedPages, XWiki.AllAttachments*, XWiki.DeletedDocuments, XWiki.DeletedAttachments and all pages used by those) --> new xwiki-platform-navigation module * Main/RssFeeds.xml --> new xwiki-platform-help module or xwiki-platform-rss-ui module (see below) * Main/SpaceIndex.xml --> xwiki-platform-navigation * Main/Spaces.xml --> xwiki-platform-navigation * Main/UserDirectory.xml --> xwiki-platform-user-ui * Main/WebHome.xml --> xwiki-platform-dashboard-ui * Main/WebRss.xml --> new xwiki-platform-rss-ui module, we would create a xwiki-platform-rss-api module too where we will move the feed plugin * Main/Welcome.xml --> move to xwiki-platform-dashboard-ui since it's a dashboard gadget which we could consider as a default widget * Sandbox/*.xml --> xwiki-platform-sandbox module (or xwiki-platform-help module) * XWiki/XWikSyntax.xml --> xwiki-platform-help module * XWiki/AttachmentSelector.xml --> xwiki-platform-user-ui or new xwiki-platform-attachmentselector module * XWiki/ClassSheet, ClassTemplate, ObjectSheet, XWikiClasses, * XWiki/GadgetClass.xml --> xwiki-platform-dashboard-ui * XWiki/LiveTableResult*.xml --> new xwiki-platform-livetable module * XWiki/MessageStreamConfig.xml --> new xwiki-platform-messagestream-ui module (and move xwiki-platform-message in xwiki-platform-message-api module) * XWiki/RequestsStatus.xml --> xwiki-platform-administration module or remove from platform till we integrate it in the Admin as an admin tool somewhere since right now I think it's available in the Admin tools application * XWiki/RequiredRightClass.xml --> since it's used in lots of other ui modules I'd propose to move it in java code as a class created on startup. Alternatively start creating a xwiki-platform-rights-ui module (or xwiki-platform-permission-ui module) and move it there * XWiki/SharePage.xml --> not sure…. maybe in a xwiki-platform-share or xwiki-platform-sharepage module * XWiki/TemplateProvider*.xml --> xwiki-platform-administration for the moment * XWiki/WebHome.xml --> xwiki-platform-administration module * XWiki/WebPreferences.xml --> xwiki-platform-administration module WDYT? Please try to tell me if you're ok for each line if you have time ;) Thanks -Vincent

9 years, 9 months

[xwiki-devs] Questions about fixing getRenderedContent() bug

by Vincent Massol

Hi, Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274 Basically if you do $xwiki.getDocument("someDoc").getRenderedContent() it'll get executed in the context of the current doc which I believe is wrong especially since other signatures of getRenderedContent() execute in the target document's context. I have fixed this locally but found that admin.vm for example is assuming that getRenderedContent() will get executed in the context of the calling doc (i.e. XWiki.Import when doing an import for example). FYI the chain flow is admin.vm -- getRenderedContent() --> XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which requires the current doc to be XWiki.Import (to get/put attachments from/to it). I can fix this easily using a new getRenderedContent signature I've introduced. However I'm wondering if we have other places that incorrectly use getRenderedContent() and assume it won't be rendered in the context of the target document. Is this change too dangerous to make? If not know, we'll need to it quickly (2.1M1?) since it's an important bug IMO. WDYT? Thanks -Vincent

9 years, 10 months

[xwiki-devs] [Contrib] Request repository for Recruitment Application

by Alexandru Chelariu

Hello, I would like to request a repository on xwiki-contrib for the Recruitment Application i am working on. I'd like the repo to be named application-recruitment and also jira component. My github username is chalx. Thank you, Alexandru Chelariu

10 years, 2 months

[xwiki-devs] [Proposal] Cleaning our POM deps by explicitly listing used dependencies?

by Vincent Massol

Hi devs, Running mvn dependency:dependency-analyze produces interesting results. For example: [INFO] --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [INFO] Building XWiki Commons - Properties 3.2-SNAPSHOT [INFO] --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- … [INFO] --- maven-dependency-plugin:2.3:analyze (default-cli) @ xwiki-commons-properties --- [WARNING] Used undeclared dependencies found: [WARNING] org.slf4j:slf4j-api:jar:1.6.1:compile [WARNING] javax.inject:javax.inject:jar:1:compile [WARNING] Unused declared dependencies found: [WARNING] org.xwiki.commons:xwiki-commons-component-api:jar:3.2-SNAPSHOT:compile [WARNING] org.xwiki.commons:xwiki-commons-test:jar:3.2-SNAPSHOT:test [WARNING] org.hibernate:hibernate-validator:jar:4.2.0.Final:test [WARNING] org.hamcrest:hamcrest-core:jar:1.1:test [WARNING] org.jmock:jmock:jar:2.5.1:test The question is (for this module but more generally for all others): * Should we add slf4j and javax.inject reps in the pom.xml for this module? (for ex today slf4j and javax.inject are found in the component-api dep) I think we should, wdyt? Note that the "Unused declared dependencies found:" doesn't always generate correct results as is the case here. This is mostly because it's a static byte code check so any dep used at runtime will be considered unused. See http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependen… Thanks -Vincent

10 years, 6 months

[xwiki-devs] [VOTE] Remove all duplicated information from folders names on git repositories

by Thomas Mortagne

Reviving http://markmail.org/message/hlnqke3igkbec332 for as an official vote. We have waited way too long and I think we really need to find a solution even if none of the committers use Windows since a long time. Every time a Windows dev even think of contributing he is very quickly discouraged... As a reminder the issue is that working on XWiki source code is a pain for MS Windows developers because of the (impossible to understand I agree) limitation on path size. So the idea is to find a new logical rule to drastically shorten our paths and Sergiu proposed the following: remove duplicated information from our paths to maven modules. Here is an example: xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-transformations/xwiki-platform-rendering-transformation-macro (131 chars) would become core/rendering/transformations/macro (36 chars) So WDYT ? Here is my +1 I also find it nicer when navigating using cd and tab in a unix shell anyway. Planning to do it in 5.1 if everyone agree. -- Thomas Mortagne

10 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2013