Some JIRA rules (was RE: [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...)
-----Original Message----- From: Ludovic Dubost [mailto:[email protected]] Sent: jeudi 7 décembre 2006 17:08 To: [email protected] 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
I know I should have had IDs. I only did it like that because these where minor changes. The null pointer was introduced by a commit the day before. The euro characters was actually a regression because someting had transformed the euro char to a question mark in the JS files. But still I agree. this is bad practice... Ludovic Vincent Massol a écrit :
-----Original Message----- From: Ludovic Dubost [mailto:[email protected]] Sent: jeudi 7 décembre 2006 17:08 To: [email protected] 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
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic
participants (2)
-
Ludovic Dubost -
Vincent Massol