xwiki-devs November 2012

xwiki-devs@xwiki.org

30 participants
78 discussions

[xwiki-devs] [VOTE] Create new xwiki-platform-application/ module

by Vincent Massol

Hi devs, I'm writing functional tests for the FAQ app in platform and I wanted to write a test for verifying that the app registers itself in the app panel. The problem is that the app panel requires UI extensions and the app panel is currently located in the panels app. However I don't want to put that as a dependency on UI extensions in the panels app since no other panel need it. So the good answer is that the app panel is not correctly located. Actually the panels ui app should only contain the Panels.WenHome page and all other panels should be part of the other functional domains… So that brings me to this proposal which is: * Create a new xwiki-platform-application/ which represents the functional domain of wiki applications. * Have 3 submodules in it as follows: xwiki-platform-application/ |_ xwiki-platform-application-manager/ |_ xwiki-platform-application-manager-api/ |_ xwiki-platform-application-manager-ui/ |_ xwiki-platform-application-appwithinminutes/ |_ xwiki-platform-application-ui/ * ATM xwiki-platform-application-ui/ would contain only the Applications Panel but in the future the content of xwiki-platform-application-manager-ui/ should be merged with it and it should for example provide a UI to list all apps in the wiki. * In the future xwiki-platform-application-manager-api/ would also be renamed in xwiki-platform-application-api/ Here's my +1 Thanks -Vincent

13 years

[xwiki-devs] 4.3 RC1 release

by Jerome Velociter

Devs, Since 4.4 M2 has been released yesterday, I propose to release 4.3 RC1 this friday instead of today. Please make sure you don't commit new stuff after tomorrow evening and help stabilize the build. Thanks Jerome

13 years

[xwiki-devs] [VOTE] Add CLIRR exclude for 2 new methods in the workspace interface for 4.3M1

by Eduard Moraru

Hi devs, Since the current policy is to ask before adding a CLIRR exclude and since I did not ask when I applied GuillaumeD's pull request [1], I hereby ask for your vote whether it is ok to exclude the 2 new methods: - that allows the creation of workspaces using a different template than the default one - that lists workspace templates Since we are tight with time (Fabio needs to finish the 4.3M1 release), this issue should be settled ASAP. Also, please note that the Workspace API is still young (and pretty basic), as far as I am concerned, and it is bound to get updated in the future. Here's my +1 Thanks, Eduard -------- [1] https://github.com/xwiki/xwiki-platform/pull/70

13 years

Re: [xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization

by Denis Gervalle

Le 9 mars 2012 16:59, "Vincent Massol" <vincent(a)massol.net> a écrit : > > > On Mar 2, 2012, at 10:06 AM, Denis Gervalle wrote: > > > On Wed, Feb 29, 2012 at 08:19, Vincent Massol <vincent(a)massol.net> wrote: > > > >> Hi, > >> > >> On Feb 28, 2012, at 12:17 PM, Thomas Mortagne wrote: > >> > >>> Hi devs, > >>> > >>> Since I plan to move some stuff from platform to commons I would like > >>> to know what you think of the history in this case. > >>> > >>> Pros including history: > >>> * can access easily the whole history of a moved file. > >> > > > > This is really an important matter, especially for those joining the > > project. When you follow XWiki from "outside", and not in a continuous > > manner, the history is of great value to understand why stuffs are like > > they are, and what you may do, or not when moving forward. > > The history is not lost. If you do a join (all active repos) you still have it. I do not know what you means by joining all repos, but I would be surprise to see the IDE find its way between them. I even wonder how it could be possible. > > >> But sometimes > >>> changing packages etc make too much difference for git to see it's > >>> actually the same file so you loose it anyway. > >> > > > > If you simply change the package name, and nothing else, it is really > > unlikely to happen. > > > > > >>> > >>> Cons including history: > >>> * double the history which make tools like ohloh indicate wrong > >> informations > >> > > > > Sure, the stats will be broken, but what is the matter. This is not > > cheating, just a misfeature in Ohloh, since the commit are just identical, > > something they may notice. IMO, this is the matter of the statistical tools > > to improve that. > > Can you tell me how to implement this because right now my GitHub tool doesn't do that and I don't know how to do it? If I had to implement it, I will probably use some hashing method to be able to recognize similar commits, since there effectively no link between them. But my main remarks that the statistics are broken, not the way we use git. > > >>> * it's a lot easier to move without history > >> > > > > There should be some tools to improve that point or we may write one, once > > for all. So this is not a real cons either. > > It's really hard to copy history in Git. It's almost impossible to do it right. You have to remember the full history and it's just too hard. I would be really disappointed to have to conclude that. There is probably some edge cases, but most of the time there is clever work around. You have to talk to Sergiu :-) > > >>> WDYT ? > >>> > >>> Even if it was looking a bit weird to me at first I'm actually +1 to > >>> not move the history in this case. > >> > >> +1, FTR I'd be -0, close to -1 to move it. If/when the source repository > >> is removed for one reason or another, then we might want to import its > >> history somewhere. > >> > > > > Seems we are really opposite on this one, since I am close to -1 to not > > move it. > > Sorry but that's the current practice :) It's also the easiest one. Until we have Git, there were no better way. This does not means that we should not improve our practice. By the way, it was not my thread, if Thomas has asked, it means that the current practice was not so current. > > > Statistics is really less valuable IMO, it is a small interest compare to > > code history, that I have use a lot, especially when I have join the > > project and follow sparingly. > > I can say exactly the same thing as you said above. It's just a question of tools since the history is not lost. It's still there in our active repos. There is absolutely no link between these histories. It is not only a question of tools. Moreover, requiring querying all active repositories to have a proper history completely defeat the purpose of having separate repositories. I do not see the comparison with my remark above. Git has been made for versionning, not for statistics, it is not my fault. > > > So the general rule for me is: Copy history when the source repository is > >> removed/deleted/not used anymore. > > How many times have you done this? I believe 0 times since I don't think you'd be so much in favor if you had tried it. I suggest you try it a few times on your own projects first :) It's really hard to do it right and very time consuming. When I have copied the security component from contrib, I have done so. I hope that I am not alone. And, frankly, it was not so hard, compare to the advantage you have. > > > You never know what will happen to a repository in the future, so this > > rules is somewhat a hope on the future, no more. And remembering that we > > may loose history if we do some change in the old repository, is for me > > like hoping you will remember my birthday ;) > > I don't agree with this at all. Again we're not loosing history. If a repo is removed then its history is copied I agree about that. I would like to know how you do that after the facts? > > >>> Eduard was proposing to include in the first commit of the new > >>> repository the id of the last commit containing the files (basically > >>> the id of the parent of the commit deleting the files) in the old > >>> repository so that it's easier to find it. I'm +1 for this. > >> > > > > But you loose all the benefits of the IDE tools that brings history of a > > selection automatically and that are really useful. > > A huge majority of xwiki's history is already lost to IDEs (when we moved from SVN) even though the SVN history was moved. Even Git itself doesn't follow the history when you move stuff around. Said differently it's alwasy possible to find the history but the IDE and "standard" tool don't follow it. It does so far better since we move to Git and it is really a valuable tool. Do you means that because in a few case, the history may be broken, that we should not try to have it as complete as possible? > > > Moreover, if the history is rewritten due to a change in structure later, > > the hash may be broken. > > Not sure I understand this one. In Git, nothing is fully permanent, that is all I say. > > You should really measure the cost of what you propose Denis. It's really hard to do. Prove me that is more cost than the one newcommers has to enter the project. Maybe you do not value history so much because you have by your own experience of the project a good knowledge of what happen in the past. When I dig in some code, I always found history valuable to understand why that piece of code is not written the way I may have expected and why I should not got that way. If Thomas conclude it is too hard to be done, and not just some developer's lazyness, I would understand; but I do not agree that it should not be done just because it breaks statistics or we think it is too hard. This is why I suggest a tools that do it once for all. I would be really disappointed of Git if we had to conclude this. Thanks, Denis > > Thanks > -Vincent > > > So having a broken history is hardening the task of those who want to > > participate. A great value compare to the statistics IMO. > > > > -- > > Denis Gervalle > > SOFTEC sa - CEO > > eGuilde sarl - CTO > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

13 years

[xwiki-devs] Community development and Marketing FOSDEM DevRoom

by Sergiu Dumitriu

This is an official call for sessions for a "Community development and Marketing" devroom, hosted at FOSDEM 2013 on Saturday, February 2nd. In this devroom, developers with different profiles and backgrounds are invited to brainstorm about aspects related to software projects which are beyond the code itself, but nevertheless crucial for keeping the project alive, such as marketing strategies useful for attracting users and contributors, processes for managing the dynamics of the community, and open source solutions for project lifecycle management. While Marketing and FLOSS have long been considered incompatible concepts, recent history has shown that marketing strategies properly tailored for the FLOSS world can be of real help for open source projects without tainting their ideology. Good marketing can be an essential instrument for reaching out and expanding the community of users and contributors. You are invited to showcase best practices and successful collaborations between marketers and developers, to discuss marketing in a typical hacker environment, and to participate in establishing a link between communities and in creating opportunities for collaboration. Furthermore, you are invited to exchange ideas about what works for keeping a community in shape: how to encourage contributions from new members, how to keep people motivated, how to work across time zones and cultures, how to handle conflicts, what are the processes for naming new committers or for accepting patches. Presenters can talk about their favorite combination of tools for version control, code review, continuous integration, issue tracking, documentation, as well as full infrastructure setup scenarios. It will be a great environment for learning from individual success stories about new ways of working better inside an open source community. If you are interested in holding a session, please submit your talk proposal no later than 23-12-2012 (UTC) by sending an email message to cdm-devroom(a)lists.fosdem.org, and providing the following information: About the speaker: - Name - Affiliation (if any) - Short bio About the proposed session: - Title - Abstract (no more than 300 words) - Preferred duration (5, 15 or 30 minutes) and time slot (optional) You can also subscribe to the mailing list to discuss the devroom topics with the two organizers, by sending an empty email message to cdm-devroom-subscribe(a)lists.fosdem.org. Looking forward to your contributions, Italo Vignoli (italo(a)italovignoli.com) Sergiu Dumitriu (sergiu(a)xwiki.org)

13 years

[xwiki-devs] document index / live table last author bug?

by Mark Wallace

In xwiki 4.1.3, there is a document index page that uses live table. It lists authors by first/last name, not their real user name. E.g. if author is user name XWiki.jgibbs, with first/last names "Joe Gibbs", the table shows "Joe Gibbs". But if I enter "joe" in the search box, I get nothing because it is actually searching the user name (XWiki.jgibbs), which does not have "joe" in it. This seems like a bug because the text shown is not the text being searched for. Has this been fixed in 4.2 or the upcoming 4.3? -- Mark Wallace Principal Engineer, Semantic Applications Modus Operandi, Inc.

13 years

[xwiki-devs] [VOTE] Functional test best practice: test order and change of configuration/creation of pages

by Vincent Massol

Hi devs, I've just added 3 items on http://dev.xwiki.org/xwiki/bin/view/Community/Testing#HSelenium2-basedFrame… and I'd like to ensure that we agree about them (if not I'll remove them): * Tests must not depend on one another. In other words, it should be possible to execute tests in any order and running only one test class should work fine. * Test chat need to change existing configuration (e.g. change the default language, set specific rights, etc) must put back the configuration as it was * Tests are allowed to create new documents and don't need to remove them at the end of the test Here's my +1 Thanks -Vincent

13 years

[xwiki-devs] [Proposal] Bug Fixing Day #7, 22 November 2012 (second try)

by Vincent Massol

Hi devs, Ok BFD #7 which was planned for the 1st of November has been cancelled since it was a day off in France (and I was on holiday at that time so I couldn't follow up on it). Hence I propose to do it on Thursday the 22nd of November (i.e. in 11 days from now). Let me know if you can attend it. Thanks -Vincent

13 years

[xwiki-devs] Bug Fixing Day #7, 1st of November

by Ecaterina Moraru (Valica)

Hi devs and contributors, According to a past vote we had [1] we are having a BFD every month on the first Thursday of every month, with the goal of reducing drastically the bug count. This month the BFD is on 1st November, which means Today. This mail is a reminder that today we are counting :) As a practice: Once you close an issue (whether you fixed it or mark it with "duplicate", "won't fix", etc) please ensure you label it with "bugfixingday" so that we can easily count them at the end of the day. You can see the current status of issues fixed during all our past Bug Fixing Days at http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11196 Let's make a dent in this stat: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Thanks, Caty of behalf of the XWiki Development Team [1] http://markmail.org/thread/np65udilrwnuekyh

13 years

[xwiki-devs] Macro inside a javascript extension

by firmusoft.xwiki

Can we call a macro from a javascript extension Thanks, Firmusoft

13 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs November 2012