January 2013 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] Have less [VOTE]s
by Sergiu Dumitriu 24 Jan '13

24 Jan '13

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

6 6

[xwiki-devs] [VOTE] Separate the power of Veto from -1 votes
by Sergiu Dumitriu 24 Jan '13

24 Jan '13

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

4 3

[xwiki-devs] [VOTE] Add CLIRR exclude for 1 new method in DataMigrationManager interface for 4.4.1 and 4.5M1
by Denis Gervalle 23 Jan '13

23 Jan '13

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

4 6

[xwiki-devs] Using a "performance" label in JIRA
by Vincent Massol 23 Jan '13

23 Jan '13

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

1 0

[xwiki-devs] Fwd: [ANNOUNCE] Apache Lucene 4.1 released
by Vincent Massol 23 Jan '13

23 Jan '13

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

1 0

[xwiki-devs] Spam on translations Wiki
by Ludovic Dubost 23 Jan '13

23 Jan '13

Hi, I've detected we have a lot of spam users on the translations wiki. I'm deleting all users that have the same first_name as last_name. If you are a translator and in this case, please email me as I can recover you account While updating the translation wiki to custom mapping, I'll upgrade it to 4.4.1 and will at the same time activate captcha registration. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

1 0

[xwiki-devs] Fwd: [ANNOUNCE] Apache Tika 1.3 Released
by Vincent Massol 23 Jan '13

23 Jan '13

Interesting for us for 5.0 -Vincent Begin forwarded message: > From: Dave Meikle <dmeikle(a)apache.org> > Subject: [ANNOUNCE] Apache Tika 1.3 Released > Date: January 22, 2013 9:22:10 PM GMT+01:00 > To: "dev(a)tika.apache.org" <dev(a)tika.apache.org>, "user(a)tika.apache.org" <user(a)tika.apache.org>, announce(a)apache.org > > The Apache Tika project is pleased to announce the release of Apache Tika > 1.3. The release contents have been pushed out to the main Apache release > site and to the Maven Central sync, so the releases should be available as > soon as the mirrors get the syncs. > > Apache Tika is a toolkit for detecting and extracting metadata and > structured text content from various documents using existing parser > libraries. > > Apache Tika 1.3 contains a number of improvements and bug fixes. Details can > be found in the changes file: > > http://www.apache.org/dist/tika/CHANGES-1.3.txt > > Apache Tika is available in source form from the following download page: > > http://www.apache.org/dyn/closer.cgi/tika/apache-tika-1.3-src.zip > > Apache Tika is also available in binary form or for use using Maven 2 from > the Central Maven Repository: > > http://repo1.maven.org/maven2/org/apache/tika/ > > In the initial 48 hours, the release may not be available on all mirrors. > When downloading from a mirror site, please remember to verify the downloads > using signatures found on the Apache site: > > http://www.apache.org/dist/tika/KEYS > > For more information on Apache Tika, visit the project home page: > > http://tika.apache.org/ > > -- Dave Meikle, on behalf of the Apache Tika community

1 0

[xwiki-devs] [VOTE] Start using proper version in branches
by Vincent Massol 22 Jan '13

22 Jan '13

Hi devs, I'd like to propose that we start using proper version names in branches. For example right now on the stable-4.4.x branch we have 4.4-SNAPSHOT as the version for all modules. This is not fully correct and it would be better to use 4.4.1-SNAPSHOT (ie the version leading to 4.4.1). As a side effect, doing this will also allow us to check the "Remove if released" option when cleaning snapshots on our Nexus. Here's my +1 to start doing this immediately and I'm volunteering to do the rename in the 4.4.x branch. Thanks -Vincent

6 5

[xwiki-devs] Help on translation using l10n.xwiki.org
by xrichard 22 Jan '13

22 Jan '13

Hello, Since I have a XWiki hosted at myxwiki.org, I'm trying to fully use it in french and I've started to update XWiki french translation. Here are some questions to help me achieve this goal "a XWiki full in french": 1. Do curriki strings also needs to be translated? Is this project still active? 2. While editing and saving a page in any Wiki, I see sentences I can not find how to translate: . bottom buttons like "Sauver & Continuer" are in french but can't find them on l10n.xwiki.org to change them, even with the new search form ;-) . little alert messages "Saving..." then "Saved" displayed at the bottom of the screen are in english but can't find them neither on l10n.xwiki.org Please see video at https://www.box.com/s/fdutid41ahh6sixpicdq with these strings. 3. more general question: I see when I go to the Wiki admin page the message "December 29: Upgraded xwiki to version 4.4-rc-1. Don't forget to upgrade your wiki". Does it mean that part of myxwiki.org upgrade is not automatic and needs to be done by each Wiki personnal admin manualy? How to check the version of my hosted Wiki to be sure this upgrade need to be done? How translations are upgraded on myxwiki.org? Thanks for your answers to clarify all these topics, regards, -- View this message in context: http://xwiki.475771.n2.nabble.com/Help-on-translation-using-l10n-xwiki-org-… Sent from the XWiki- Dev mailing list archive at Nabble.com.

4 6

[xwiki-devs] Rewrite the "Notifications Tutorial" page
by Manuel Smeria 22 Jan '13

22 Jan '13

Hi everyone, Can someone please rename the "Notifications Tutorial" page<http://platform.xwiki.org/xwiki/bin/view/DevGuide/GroovyNotificationTutorial>, rewrite it and explain: 1. how to write a listener in java 2. how to write a listener in groovy 3. how to write a listener using wiki components 4.

1 1