xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [PROPOSAL] So what do we do for our Maven projects names

by Thomas Mortagne

Hi devs, In order to automate the update of extensions imported from https://github.com/xwiki/ we need to have nothing to modify when an import is done. The last remaining thing is the name on which there is a debate is the name. Right now the name we have in our maven project looks like "XWiki Commons - Extension - Repository - Maven" so that's what we get when importing this project or when viewing it in EM UI. Some of us want to keep this idish name for Maven build but don't like it when displaying extension. I recently introduced a way to overwrite some extension related informations like the name based on properties. So here are the choices we have: 1) Do nothing which mean display "XWiki Commons - Extension - Repository - Maven" in EM UI and extensions.xwiki.org 2) Change our naming in Maven <name> property for it to be more a name than an id that would looks good in EM UI 3) Keep the same naming for Maven <name> and overwrite it everywhere using <xwiki.extension.name> property So, WDYT ? The one that makes the more sense to me is 2) so my +1 goes to this one. Frankly I don't care too much having the current id based display of the summary of built modules in Maven build and I personally won't have any issue to know what name correspond to what project (but that's because I know them well, I can understand new dev could be a bit more lost). Then: * +0 for 3) to +0 (I don't like too much having this special case everywhere in our Maven pom.xml) * -0 for 1) (I agree that it does not looks very nice as a display name). -- Thomas Mortagne

11 years, 11 months

[xwiki-devs] internationalization of DBTreeList

by Paul Libbrecht

Hello fellow XWikiers, Yesterday we released Curriki 1.13.1 and realized that one of our cluster nodes was actually speaking French for the subjects tree. This really felt like... a french-speaking-guy saved the wrong thing, I was under high suspicion! ;-). I dug the code for quite a while then found it: the subjects display simply uses doc.display(field). So it all happens internally. After a while, I realized that caching was quite intensive, which explains why it's working well. However, I also saw that this caching was actually implying that these tree-lists are monolingual, because treeview.vm uses item.value to express the labels. Is there a reason to not use i18n objects, in javascript or in velocity, there? thanks in advance Paul

11 years, 11 months

[xwiki-devs] Users and Groups not available after updating from 2.7* to 4.2

by echocoder

I migrated from Xwiki 2.7.33656 to version 4.2. In doing so, I seem to have lost my user and group objects. I exported the Xwiki from the previous version and just reimported into the new install of 4.2. The Admin console seems to hang when listing users or groups, I also cannot add either. Did the location of the user/group objects change in 4.2? Can anyone tell me why an export from 2.7* followed by an import in 4.2 would not transfer these objects correctly? -- View this message in context: http://xwiki.475771.n2.nabble.com/Users-and-Groups-not-available-after-upda… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 11 months

[xwiki-devs] Issue with the document translation bundle created by AWM

by Marius Dumitru Florea

Hi devs, In order to implement http://jira.xwiki.org/browse/XWIKI-8584 I had to choose between using the document translation bundle on demand (only when needed) and using it automatically (in some scope). The problem with on demand is that if you have a live table you need a custom live table results page just to demand the translation bundle when live table results are fetched. So I decided to use wiki scope, but, as it turns out, you need special rights to register a document translation bundle on the entire wiki. A simple user creating an application with AWM won't have the application translation bundle registered. The reason I choose the 'wiki' scope is that there was no 'space' scope. Space (application) scope makes a lot of sense in my case and I'm wondering if it's hard to implement it. Note that I already make the application creator an admin of the application space, so requiring space administration rights for space scope is fine for me. WDYT I should do for 4.5: (1) use the document translation on demand and generate a custom live table results page or (2) push for Thomas to implement space scope if it's simple :) Thanks, Marius

11 years, 11 months

[xwiki-devs] [ANN] XWiki 4.4.1 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 4.4.1 This is a bugfix release. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki441 Thanks -The XWiki dev team

11 years, 11 months

[xwiki-devs] [VOTE] Have less [VOTE]s

by Sergiu Dumitriu

Short story: We should have less VOTEs, since too many votes is tiresome and counter-productive. A vote should be fired only for critical stuff, or when a compromise solution between suboptimal alternatives is needed. Long story: According to the rules [1], a VOTE comes with strong requirements on the committers: every committer must respond to votes, and vote only after carefully analyzing and understanding what's being voted. In theory, this has several benefits: - it ensures the openness, democracy and meritocracy of the community - it ensures that all the affected parties can make their voice heard when changes might affect them - it lets the community know about big changes in the code, even if not everybody votes - it tries to maximize the quality of the code, since every design is first validated by all the sharp minds participating in the project - it tries to maximize the global shared ownership of the code, since every developer gets involved in everyone else's code And all these are good goals, but when too much votes occur, downsides emerge: - decision fatigue [2], which means that votes get less attention, and +1-ing is just an automated process -- +1 after reading just the subject, or +1 if someone trusted already voted - decision paralysis [3] will actually cause committers to stop voting altogether on non-essential issues - developer frustration, when every change has to be discussed at length -- in theory, the vote process rules explicitly say that only major changes must be voted, and even for major changes, only when the committer isn't sure that everybody else will agree with the vote; however, recently there has been an increase in the situations in which things must be voted, and in most weeks several votes are started --- [4] says that 103 votes were started last year, almost two every week - reduced efficiency, less time for actual coding, since a lot of time is spent on trying to understand what's being proposed in the votes - it transforms the democracy into a bureaucracy - it reduces the self-confidence of developers; in theory, a contributor becomes a committer when the other committers consider him/her to have the required knowledge, skills and overall understanding of the XWiki code and guiding principles to be allowed to freely commit their own changes. In practice, most changes still have to be discussed, voted, validated before the actual commit can happen. - while the vote right mean that all committers can say their opinion, it also means that the vote is a two-way obligation, the obligation to have their opinion validated by everybody else, and the obligation to get involved and validate everybody else's code I've been monitoring a few other communities, especially Apache projects, the ones that we're supposedly modeled after, and I haven't seen this huge amount of votes in any of them. Votes are actually exceptional events, when something important happens: - new committers - releases - major infrastructure changes, like switching from Ant to Maven, or from SVN to Git For example, the Velocity project had 15 votes in the past three years [5]. Maven had 125 votes last year, but almost all of them are release votes, one for every plugin, and they have a lot of plugins [6]. So I'm proposing to stick closer to the original voting rules, which means that votes are sent only for major changes (in code, infrastructure or community), and rely more on the lazy consensus advertised in the vote rules [1]. Some of the purposes that the current vote requirements try to address can be accomplished by other means: - API changes can be just announced - code changes should rely on lazy consensus, and committers should spend more time doing commit reviews - we can use feature branches and pull request more often, since a pull request is a request for comments - we can go back to trusting the skills and common sense of our committers [1] http://dev.xwiki.org/xwiki/bin/Community/Committership#HVoting [2] http://en.wikipedia.org/wiki/Decision_fatigue [3] http://en.wikipedia.org/wiki/Decision_fatigue#Decision_paralysis [4] http://xwiki.markmail.org/search/?q=subject%3Avote+date%3A201201-201212+-su… [5] http://velocity.markmail.org/search/?q=subject%3Avote+date%3A201001-201212+… [6] http://maven.markmail.org/search/subject:vote+date:201201-201212+-subject:r… -- Sergiu Dumitriu http://purl.org/net/sergiu

11 years, 11 months

[xwiki-devs] [VOTE] Separate the power of Veto from -1 votes

by Sergiu Dumitriu

Short story: A Veto carries a lot of power [1], and it brings imbalance to a supposedly democratic process. For normal votes, especially those that ask for opinions, not for validation of a critical decision, a -1 should count as a normal vote. In this case, an actual Veto should be marked as such. Proposals: A. Keep -1 as a Veto, but require the voter to really justify the veto with technical reasons. If the vetoer fails to convince other of his reasons, and the majority still agrees with the proposal, then the veto can be discarded, and the vote passes. B. Separate -1 from Veto. A -1, by default, counts just as a vote against the proposal, and the majority will rule. An actual Veto must be marked as such, but the vetoer must bring very good reasons for the veto. C. Just keep things as they are now, since you think that the current process has worked well so far, and nobody abused the right to veto. Long story: The right to Veto a VOTE means that just one participant can block a whole vote, even though the vast majority thinks otherwise. This is a very powerful right, and I for one tried to avoid using it as much as possible: in general I use -0 for solutions that I don't particularly like, but for which I don't have an actual better solution, or an universally acceptable reason that can convince everybody else of my decision. It makes sense to have the Veto power, as a way to spotlight serious problems with a proposal. The expected outcome in this situation is for the vote sender to understand and accept the outcome, and go back to redesigning the proposed solution, fixing the problems exposed. But when votes are just about opinions, and about choosing the version that most people like, it is hard to say that one opinion is more important than others and it can rightly prevent reaching a conclusion. This is particularly true about UI design and UX, but also about voting on processes and rules. One possible outcome is that votes (and the proposals being voted) get deadlocked, blocking progress. The rules say that the proponent should review and change the proposal and restart the vote. Sometimes the effort put into the original proposal is considered big enough, and if the vetoer failed to convince the proponent of the problems, there won't be any more work put into the proposal, and it will just die. I'm not saying that this happens too often, but it does from time to time, at least for me. So, I think that the Veto power should be used sparingly. I see two options: A. Keep -1 as a Veto, but require the voter to really justify the veto with technical reasons. Currently, the rules say that the vote sender must try to convince the vetoer about the rationale of the voted proposal. It should also be the other way around: if the majority agrees with the proposal, the vetoer should try to convince the others why the proposal is bad. If the vetoer fails to do that, and the majority still agrees with the proposal, then the veto can be discarded. B. Separate -1 from Veto. A -1, by default, counts just as a vote against, and the majority will rule. -1 keeps its power as a strong opinion against the proposal, and it should be justified and the voter should try to convince others why the proposal is bad. A -1 can still influence other voters and can change the outcome when the concerns raised in the motivation for the -1 are accepted as valid. We can put more weight into the -1, so for example a vote passes if (2*-1s) + (+1s) > 0, or (-1s) + (+1s) > 3, or another balanced variation. An actual Veto must be marked as such, but the vetoer must bring very good reasons for it. I'm +1 for either proposal, leaning towards 2, since it's clearer when a vote can be passed or not. To offer the other alternative: C. Just keep things as they are now, since you think that the current process has worked well so far, and nobody abused the right to veto. [1] http://dev.xwiki.org/xwiki/bin/Community/Committership#HVoting -- Sergiu Dumitriu http://purl.org/net/sergiu

11 years, 11 months

[xwiki-devs] [VOTE] Add CLIRR exclude for 1 new method in DataMigrationManager interface for 4.4.1 and 4.5M1

by Denis Gervalle

Hi devs, For this one, I though it is trivial, but the rule being the rule, here is the vote to add the following exclusion: <difference> <className>com/xpn/xwiki/store/migration/DataMigrationManager</className> <method>com.xpn.xwiki.store.migration.DataMigrationStatus getDataMigrationStatus()</method> <differenceType>7012</differenceType> <justification>New method to allow building an UI for reporting migration issues (mainly for sub-wiki)</justification> </difference> Since I need it ASAP, will commit that one upfront, and I will revert if anyone disagree. Hope this works for you, here is my +1. -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

11 years, 12 months

[xwiki-devs] Using a "performance" label in JIRA

by Vincent Massol

Hi devs, Since one of the goal for 5.x is to improve performance, I think it would be good to start listing all issues related to performance in JIRA. I've started using the "performance" label. Thus if you find any issue related to performance please try using that label so that we can have a good global picture of all there is to do. Thanks -Vincent

11 years, 12 months

[xwiki-devs] Fwd: [ANNOUNCE] Apache Lucene 4.1 released

by Vincent Massol

To plan for 5.0… (same for SOLR). -Vincent Begin forwarded message: > From: Steve Rowe <sarowe(a)apache.org> > Subject: [ANNOUNCE] Apache Lucene 4.1 released > Date: January 22, 2013 5:21:50 PM GMT+01:00 > To: "dev(a)lucene.apache.org" <dev(a)lucene.apache.org>, "java-user(a)lucene.apache.org" <java-user(a)lucene.apache.org>, "general(a)lucene.apache.org" <general(a)lucene.apache.org>, announce(a)apache.org > > January 2013, Apache Lucene™ 4.1 available > > The Lucene PMC is pleased to announce the release of Apache Lucene 4.1. > > Apache Lucene is a high-performance, full-featured text search engine > library written entirely in Java. It is a technology suitable for nearly > any application that requires full-text search, especially cross-platform. > > This release contains numerous bug fixes, optimizations, and > improvements, some of which are highlighted below. The release > is available for immediate download at: > http://lucene.apache.org/core/mirrors-core-latest-redir.html > > See the CHANGES.txt file included with the release for a full list of > details. > > Lucene 4.1 Release Highlights: > > * Lucene 4.1 has a new default codec (Lucene41Codec) based on the > previously-experimental "Block" indexing format for improved > performance, but also incorporating the functionality of "Appending" > and "Pulsing". > > * The default codec incorporates the optimization of Pulsing: terms > that appear in only one document (such as primary key/id fields) just > store the document id in the term dictionary instead of a pointer to > this document id in a separate file. > > * The default codec incorporates an efficient compressed stored fields > implementation that compresses chunks of documents together with LZ4. > (see > http://blog.jpountz.net/post/33247161884/efficient-compressed-stored-fields…) > > * Lucene no longer seeks when writing files (all fields are written in > an append-only way). This means it works by default with append-only > streams, hdfs, etc. > > * New suggest implementations: AnalyzingSuggester, where the underlying > form (computed from a lucene Analyzer) used for suggestions is > separate from the returned text (see > http://blog.mikemccandless.com/2012/09/lucenes-new-analyzing-suggester.html), > and FuzzySuggester, which additionally allows for inexact matching on > the input. > > * Near-realtime support was added to the facet module. > (see http://shaierera.blogspot.com/2012/11/lucene-facets-part-1.html) > > * New Highlighter (postingshighlighter) added to the highlighter > module. (see > http://blog.mikemccandless.com/2012/12/a-new-lucene-highlighter-is-born.html) > > * Added FilterStrategy to FilteredQuery for more flexibility in > filtered query execution. > > * Added CommonTermsQuery to speed up queries with very highly frequent > terms. Term frequencies are efficiently detected at query time - no > index time preparation required. > > * Several bugfixes and optimizations since the 4.0 release. > > Please read CHANGES.txt for a full list of new features. > > Please report any feedback to the mailing lists > (http://lucene.apache.org/core/discussion.html) > > Note: The Apache Software Foundation uses an extensive mirroring network > for distributing releases. It is possible that the mirror you are using > may not have replicated the release yet. If that is the case, please > try another mirror. This also goes for Maven access. > > Happy searching, > Lucene/Solr developers

11 years, 12 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs