2 consequences:
* work on 5.0 can now start. on master,
* anyone who needs to commit some important bug fixes for 4.5 need to do so on stable-4.5.x
Thanks
-Vincent
Hi devs,
We've closing the 4.x cycle and here's the result of bugs fixed vs bugs created during the past 360 days:
http://snag.gy/MZxh7.jpg
As you can see:
* More issues were created than fixed: 919 created vs 844 fixed
* During the whole time, the red has been winning
What this means is that overall we're loosing the quality war. Of course bugs are not evenly distributed and it may happen that created bugs are peripheral but they're still bugs and since they've been reported they have affected users…
Thus I propose that for the 5.x cycle we take some drastic action and do a Bug Fixing Day every week in en effort to have green be the default (ie more bugs fixed than created).
At least it would be great if we could try it for a while and see how it goes.
If you agree, what about doing that every Thursday, starting with the 21st of February(since 11th is the final 4.5 release)?
WDYT?
Thanks
-Vincent
PS: To see past BFD events, see:
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikiDa…
Hi devs,
I`ve just pushed (to master and stable-4.4.x) a fix for a workspace bug [1]
that caused problems when a workspace name/ID contained an underscore. I am
mentioning this because the fix required, in order for it to be a proper
fix, that I do a clirr violation (remove the wikiName parameter from the
createWorkspace method because it was misleading).
Since this API is not used in any XWiki module that I know of, not in any
third party code either (correct me if I`m wrong), I think that the clirr
exclusion will not create new issues.
Just wanted to mention it. If someone does not agree with this decision,
please let me know so that we can make a better one.
Thanks,
Eduard
----------
[1] http://jira.xwiki.org/browse/XWIKI-8394
Hello all,
FYI I've transfered the xwiki-social-login from my account to
xwiki-contrib on github.
Old references should still work as I've cloned it in my account.
Jerome
Hi devs,
I've installed the UI of a wiki through DW and I've noticed that the Sandbox.WebHome page had 2 revisions instead of the 1 revision I was expecting.
The first revision has a comment that says "Import: add attachment" and the second rev has a comment of "Import: final save".
However, if I skip the DW and import the XAR, I'll get only 1 revision AFAIK.
Is this discrepancy normal? Do we want it?
Thanks
-Vincent
Hi devs,
Similar to commons and rendering, we now have a CI job at http://ci.xwiki.org/view/Platform/job/xwiki-platform%20Quality%20Checks that runs every night and that checks if TPC thresholds are ok. If not a failure email is sent to the list and whoever caused the failure is supposed to add more tests to go back to the TCP level defined in the pom.xml of that module.
This is the last step of http://markmail.org/thread/j5yuaxixbyvytfr3
Let's hope we can make this work and keep increasing the xwiki project's quality as a consequence! I'm sure we'll find some issues but they'll be occasions to discuss quality and testability of our code :)
Thanks
-Vincent
Hi devs,
A missing peace of Extension Manager UI is the fact that the log
associated to a task is not translatable right now. So I'm working on
making easy to translation log in general since that's actually what
EM is displaying: just plain standard slf4j log (see
http://jira.xwiki.org/browse/XCOMMONS-304).
= Possibilities =
Here are several possibilities:
1) translate the message before giving it to the log event, so it's up
to the log producer to translation its log based on the context
language
2) provide an additional translation key along with what will now be
the default message when logging
3) generate a translation key based on the default message
Here is what I think of those:
1) is a bit better for the user than the current situation but not
that much, instead of behind stuck with english he will be stuck with
another language with stored logs. It also make anyone that produce
log depends on many things to actually translate that message so it's
a -1 for me
3) sounds very fragile
= The actual proposal =
Here is a detailed proposal for 2):
The idea would be to pass the translation key using slf4j Marker API.
We introduce a TranslationMarker which implements Marker and is passed
with the log when you want to associated a translation key to a log.
Here is an example:
producer (for example the install job):
""
logger.error(TranslationMarker.getMarker("some.translation.key"), "A
default error message generally in english with a [{}]", "parameter",
exception)
""
displayer (for example the Extension Manager UI, should be a logging
module UI element btw reused by Extension Manager ;)):
""
#set($translationKey = $logEvent.marker.translationKey)
""
WDYT ?
--
Thomas Mortagne
Hi devs,
I've been working in the 4.3 Roadmap for a new skin proposal. You can see
it at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x
I recommend looking at the "Annotations Overview" gallery in order to see
the different elements of the skin and some explanations.
I've made also separate pages for different components of the skin. For
example, you can see more information about how the menus work at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4xMenus
For each component you can also see how the elements scale and see the
responsive layout.
For the record, the proposal is made by using Bootstrap (
http://twitter.github.com/bootstrap/).
Thanks,
Caty
Working on l10n change to custom mapping showed up an issue with the l10n
history.
We have a huge history table with 2,3M lines (as well as an activity
stream) and we use the history table for extracting contributor statistics.
However looking at it more closely shows that the source of most data in
the history table is useless.
See here a grouping by dates showing that localisation of already close to
2M lines in 6 month in 2012.
| 201201 | 318346 |
| 201202 | 311403 |
| 201203 | 728703 |
| 201204 | 271657 |
| 201205 | 296384 |
| 201206 | 120463 |
Here is an example of history for an entry
mysql> select
xwr_author,xwr_version1,xwr_version2,xwr_date,xwr_comment,cast(xwr_isdiff
as unsigned), length(xwr_patch) from xwikircs where xwr_docid=596494851 ;
+-----------------------+--------------+--------------+---------------------+-------------+------------------------------+-------------------+
| xwr_author | xwr_version1 | xwr_version2 | xwr_date
| xwr_comment | cast(xwr_isdiff as unsigned) | length(xwr_patch) |
+-----------------------+--------------+--------------+---------------------+-------------+------------------------------+-------------------+
| XWiki.XWikiTranslator | 1 | 1 | 2010-02-23 11:38:27
| | 1 | 163 |
| XWiki.XWikiTranslator | 2 | 1 | 2010-02-23 11:40:26
| | 1 | 330 |
| XWiki.rbuj | 3 | 1 | 2010-03-04 00:24:24
| | 1 | 189 |
| XWiki.rbuj | 4 | 1 | 2010-03-04 01:02:52
| | 1 | 223 |
| XWiki.rbuj | 5 | 1 | 2010-07-30 01:12:58
| | 0 | 5026 |
| XWiki.XWikiTranslator | 6 | 1 | 2012-01-23 11:40:25
| | 1 | 115 |
| XWiki.XWikiTranslator | 7 | 1 | 2012-01-23 11:58:25
| | 1 | 115 |
| XWiki.XWikiTranslator | 8 | 1 | 2012-01-23 13:31:52
| | 1 | 234 |
| XWiki.XWikiTranslator | 8 | 2 | 2012-01-23 15:36:02
| Prepared | 1 | 115 |
| XWiki.XWikiTranslator | 8 | 3 | 2012-01-24 02:01:12
| Prepared | 0 | 5670 |
| XWiki.XWikiTranslator | 8 | 4 | 2012-01-25 02:04:00
| Prepared | 1 | 115 |
| XWiki.XWikiTranslator | 8 | 5 | 2012-01-26 02:02:29
| Prepared | 1 | 115 |
| XWiki.XWikiTranslator | 8 | 6 | 2012-01-27 02:01:18
| Prepared | 1 | 115 |
| XWiki.XWikiTranslator | 8 | 7 | 2012-02-04 02:01:08
| Prepared | 1 | 115 |
| XWiki.XWikiTranslator | 8 | 8 | 2012-02-07 02:02:03
| Prepared | 0 | 5670 |
| XWiki.XWikiTranslator | 8 | 9 | 2012-02-08 02:01:20
| Prepared | 1 | 115 |
| XWiki.XWikiTranslator | 8 | 10 | 2012-02-14 02:01:07
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 11 | 2012-02-28 02:01:32
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 12 | 2012-03-03 02:01:20
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 13 | 2012-03-14 02:01:50
| Prepared | 0 | 5671 |
| XWiki.XWikiTranslator | 8 | 14 | 2012-03-14 18:23:06
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 15 | 2012-03-14 18:32:38
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 16 | 2012-03-14 18:37:17
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 17 | 2012-03-24 02:01:34
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 18 | 2012-03-26 16:40:35
| Prepared | 0 | 5671 |
| XWiki.XWikiTranslator | 8 | 19 | 2012-03-28 02:01:23
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 20 | 2012-03-29 02:01:45
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 21 | 2012-04-11 02:01:36
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 22 | 2012-04-19 15:20:10
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 24 | 2012-04-29 02:01:45
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 25 | 2012-05-04 18:55:30
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 26 | 2012-05-04 19:02:09
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 27 | 2012-05-10 02:04:36
| Prepared | 1 | 116 |
| XWiki.XWikiTranslator | 8 | 28 | 2012-05-30 02:02:08
| Prepared | 0 | 5671 |
| XWiki.XWikiTranslator | 8 | 29 | 2012-06-07 10:44:28
| Prepared | 0 | 5782 |
+-----------------------+--------------+--------------+---------------------+-------------+------------------------------+-------------------+
http://l10n.xwiki.org/xwiki/bin/view/XE/XEXWikiCoreResources_2107067965_cor…
Most entries are "no changes" and have been cause by the L10NUpdater which
wrongefully saved the document with no changes. I believe this must have
been fixed (by Thomas M.?) mid 2012.
Now the 2M lines impact performance significantly and loads the DB for
nothing (and in the activity stream as well).
I suggest we clean up the history and activity stream. We have 2
possibilities:
For xwikircs:
1/ Clean up only the bad data from XWikiTranslator when there are no
changes:
This is complicated as you need to verify if the change is actually a
change and you cannot do that just with sql queries. It could be very long
2/ Clean up old data from pre-201206 from XWikiTranslator
Simpler if it is safe to delete by date in the DB. After discussion with
sergui this is a bit complicated because you need to make sure you don't
delete the latest full version before the versions you keep. So you would
have to do it by API which will take ages.
3/ Clean up up old data from pre-201206 from all users
This is simpler as you can safely delete from the database everything older
than a certain versions. Cleans-up even more but would loose contributor
statistics unless we store 2012 contributor counts in an alternate table
which would then be regularly updated
In any case we should probably create this intermediary table for
statistics as it would be much faster anyway.
For activitystream:
1/ Clean up old data from XWikiTranslator 201206 or earlier
2/ Clean up old date from everybody 201206 or earlier
What value do we see in the l10n history and actvity stream and which
solutions do the other commiters suggest ?
I would say it's interesting for contributor statistics (counting number of
contribution by translators) but beyond that we can delete the data.
So we would fix that by storing monthly statistics in a table and updating
the latest 2 month through a scheduler job. This means that we can also
delete history over 2 month.
WDYT ?
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi devs,
We're very late for the 4.5 release. Here are the dates we planned initially (see http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome):
* 4.5M1: 14th of Jan 2013
* 4.5RC1: 21st of Jan 2013
* 4.5 Final: 4th of February 2013
Here are outstanding issues currently marked for 4.5M1:
http://jira.xwiki.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=fixVer…
Since we're late and since there are already interesting changes in 4.5M1 (see RN: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki45M1), I'm proposing to have the following new dates:
* 4.5M1: Monday 28th of Jan
* 4.5RC1: Monday 4th of Feb
* 4.5Final: Monday 11th of Feb
WDYT? (that's one week of delay compared to original plan)
Volunteers are also welcome to act as Release Manager for these releases. Barring that I'll do it but I'm getting a bit tired (I've done the last 4 releases).
Thanks
-Vincent
Hi devs,
I am currently working on XWIKI-8718 (
http://jira.xwiki.org/browse/XWIKI-8718) to improve the reporting of failed
or missing migration directly in the error reported by the browser. To do
so, I keep a cache of the exceptions generated by migrations, and reattach
them to all access failure to a given database. This will really help the
end user, since it is no more necessary to dig the logs to notice a
duplicate key issue in a migration.
However, during a simple initial request to XWiki, a lot of access is done
to the database, and many of them are not fatal (especially in a farm with
a valid main wiki), but reports warnings or errors to stdout. This produce
between 5K (main wiki had failed) to 22K lines (a subwiki has failed).
Most of them are caused while getting a value in preference of user, space
or wiki. And since these are linked together, in a fallback manner, getting
a user preferences cause three error reports and space two.
Currently these errors are logged at WARN level. Since all these are not
fatal, and provide correct fallbacks for the current situation, I would
like to reduce that log level to DEBUG. Doing so will significantly
simplify the logs (around 2K lines), and avoid really repetitive reports,
since each access to a single value of the preferences are reported
individually.
Here is my +1 to reduce to DEBUG, the log level of:
XWiki#getUserPreference(String prefname, XWikiContext context)
XWiki#getSpacePreference(String preference, String space, String
defaultValue, XWikiContext context)
XWiki#getXWikiPreference(String prefname, String fallback_param, String
default_value, XWikiContext context)
WDYT ?
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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
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
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.
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
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
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
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
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
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