> -----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
