-----Original Message-----
From: Ludovic Dubost [mailto:ludovic@users.forge.objectweb.org]
Sent: jeudi 7 décembre 2006 17:08
To: xwiki-commits(a)objectweb.org
Subject: [xwiki-commits] r1696 - in xwiki/trunk:
core/src/main/java/com/xpn/xwiki/doc
core/src/main/java/com/xpn/xwiki/plugin/lucene
tests/java/com/xpn/xwiki/test
web/standard/src/main/webapp/wiki_editor/plugins
web/standard/src/main/webapp/wiki_editor_2/plugins
Author: ludovic
Date: 2006-12-07 17:08:27 +0100 (Thu, 07 Dec 2006) New Revision: 1696
Modified:
xwiki/trunk/core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java
xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/lucene/ObjectData.j
ava
xwiki/trunk/tests/java/com/xpn/xwiki/test/XWikiTest.java
xwiki/trunk/web/standard/src/main/webapp/wiki_editor/plugins/core.js
xwiki/trunk/web/standard/src/main/webapp/wiki_editor_2/plugins/core.js
Log:
Added tests for copyDocument
fix null pointer in lucene object indexing fix null pointer in clone
fix euro characters in wysiwyg editor (sorry no jira IDs)
The important question is whether the lucene object indexing n the clone and wysiwyg
editor did not exist before the current release (1.0 beta1). If they did then XWiki users
need to know they have been fixed.
When the times come for releasing XWiki 1.0 beta 1 I guess we'll use JIRA for creating
the change log. I don't think the XWiki project has ever done that yet. This is an
interesting time because it shows the rules that have to be applied for making useful
change logs:
1) You'll see that issue summary needs to be clear, up to the point and in user
parlance, i.e. they need to explain something that any end user would understand. For
example not something like "fix null pointer in XWikiSomeClass" but rather
"Fix error when clicking on a blog item".
2) There are lots of non-necessary issues that should be grouped together. For example
there should only be one issue for "Implement v2 of the WYSIWYG editor". If
there are 10 one them, like one for fixing a newly introduced bug in v2 of the editor or
some issues for the details of the implementation then it'll only muddy the changelog
and confuse the users. This is what I was trying to convery when I wrote the earlier email
about IDD and JIRA. It's possible that this SVN diff corresponds to this kind of case
(if that's true then the JIRA # should be existing ones).
3) There are some other categories of JIRA issues that our end users should not see. For
example build-related issues should be removed from change logs. Same for machine
infrastructure things (like ensuring that the jira emails go to the mailing list, etc). In
order to be able to exclude these easily we need to have components for them (this is why
I created the Build component some time ago BTW).
4) We should always practice IDD as otherwise we'll be missing change log items when
we export the jira issues for creating our changelog. This means we won't be able to
trust JIRA and we'll have to remember what we've done which is pretty
impossible...
Thanks
-Vincent
___________________________________________________________________________
D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions !
Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo!
Questions/R�ponses
http://fr.answers.yahoo.com