BUG跟踪技术在文档化项目管理中的应用

duligavin

大家好！
感谢EQUN，还有感谢志愿者们，翻译工作很棒！
衷心祝愿EQUN能发扬光大！

                      BUG跟踪技术在文档化项目管理中的应用
这是一种采用软件测试的观念，来解决目前“分布式志愿计算”的志愿者们在参与的项目中所面临的一些问题的探讨。也谈不上什么技术，自己搜索了很多文章，这里就谈谈个人的一点儿陋见。

建议：
采用以版本控制的方法辅助进行各种翻译或其他工作的交付与安排。

把做完的项目，现在正在做的项目，未完成的项目，更直观的将进展情况公布出来。

问题：
我非常赞赏志愿翻译工作者，由于大家都是志愿参与而且翻译的工作量十分巨大，谁也不可能确保做到项目完美结束，所以解决上述问题需要一定的开发工具辅助工作。

以前都是采用论坛发帖这种功能来实现各个项目的翻译等工作，这种形式的发布系统越来越无法满足可视化需求，造成前人的维护工作难以持续，且新志愿者加入又非常不方便。

所以需要采用一种可以可视化的，在一定程度上形成工作流,这样就不会因为负责人的个人因素导致项目停顿。

我已翻阅以前翻译版块的帖子，发现其中存在一些翻译工作的困难。

“MEDIAWIKI”目前依个人所知还没有流程规划工具，流程规划：这里主要指使用软件的版本控制方法进行BUG测试管理并应用于翻译中，甚至应用于日常管理流程。现在各版主工作的主要难点就在于流程的可视化程度不够，不利于新志愿者参与项目，最终因缺乏“新鲜血液”无法持续更新，影响相关项目的同步。

“MEDIAWIKI”现在可以做到添加和修改页面后，显示出历史上的修改版本，能使新旧文件的版本有一个可视化对比，WIKI界面友好等，这些功能优于使用论坛提供的聊天功能进行组织翻译，此方法已得到大家拥护。但志愿者们依然缺乏整体的组织工作，没有形成流程，致使如果后期缺少相关负责人依然有可能导致项目不了了之，这方面存在一定程度的管理不规范。

方向：
结合制作开发文档的方式，形成总体规划，弥补组织工作中因个人问题导致项目停顿，从整体外观上可以看到各自工作进展，方便新加入的志愿者直接了解并参与项目，从而减轻负责人的工作量。

可视化的便捷性带来的好处是有可能解决曾经未解决的一些问题:
1.论坛内有很多帖子的链接无效，长期没有进行适当管理。
引用：
http://boinc.equn.com/dev/myers.html
http://www.equn.com/forum/thread-12434-1-1.html
http://www.equn.com/forum/thread-4206-1-5.html
http://www.equn.com/copyright.htm

2.论坛帖子保留了旧的内容，但是缺乏持续更新。
引用：
http://www.equn.com/eon/
http://www.equn.com/forum/thread-14031-1-2.html


3.翻译规则细节方面不够明确，统一一个页面用来系统的介绍术语会更高效。
引用依据18楼：
http://www.equn.com/forum/thread-9980-2-2.html
在天体物理学中，重力和引力好像是可以不加区分的认为全等。
以后我们都用引力好了....

4.翻译工作结果未知,后续回帖中实际已经翻译完的项目，负责人没更新页面。
引用：
（1）http://www.equn.com/forum/thread-15614-1-2.html  
（2）http://www.equn.com/forum/thread-10791-1-3.html


5.工作进展不够显而易见，造成重复劳动。虽然有提前声明者，但新加入的志愿者需要翻旧帖才能发现什么是翻译过的。今天我尝试翻了一下旧帖，掺杂的无关内容使我“头大”。这样不利于查找细节错误，挑错是比较艰巨的任务，文档杂乱无章非常影响阅读效率，无形中丧失了机会。
（1）引用依据42楼：                        
http://www.equn.com/forum/thread-9980-3-2.html
楼上的这个页面我们不是早已翻译过的吗？请浏览
（2）引用依据3楼：
http://www.equn.com/forum/thread-11023-1-2.html
翻译之前要在这边先发个帖子，说一下，以避免重复翻译的.....前几天，我在 QQ 上难得碰到 W.polly 一次，我还提翻译的事情了，本来是
想和他一起翻译 SoB 的，还好，我和他都忙，要不然，又要撞车了..

说明：以上这些问题是我最近收集的，但我无法确定以后修复的情况，我将及时更新错误内容。
对于修复后的错误，我想我应该有权保留《这些曾经在历史版本中出现的错误的》意见（自己有些糊涂了，您不会比我还糊涂吧～～）。修复后的错误链接不必太斤斤计较了，重要的在下面。

实现方法：具体细节需要志愿者们共同归纳，这里只做一个初步的探讨：
（1）从首页找到 规则，查看分析历史记录，从数据库中下载信息。
（2）从相应扩展菜单（＋号扩展）中找信息。
（3）对感兴趣的信息主动认领，确定完成时间。
（4）一个任务完成后确定更新状态。
（5）同步发布WIKI。

总结：可能有不对的地方且不能面面俱到，如有不恰当的欢迎指正。

这种方法的优点在于：界面人性化，时间版本全程跟踪，BUG及时更新。
目前“BOINC”的官方“WIKI”采用“TRAC”，最近又把部分文档工作实现到了“MEDIAWIKI”中，前者由于内部集成了版本管理，完善了WIKI在BUG版本管理方面的不足。“TRAC”的技术性与“MEDIAWIKI”的漂亮页面的珠联璧合，使文档规范化并可有效减少管理员工作量。

可以参考http://code.google.com/hosting/中的各个开源项目的中文翻译文档工作。

虽然是简单的软件代码管理，但是有利于组织管理工作。国内某些翻译项目已在此平台上开展了部分工作，值得借鉴。当然也可以内部自己搭建类似的平台。

成果：
为保护EQUN志愿计算爱好者们的资源不被非法利用，我已提前在code.google注册了两个项目。

“CODE.GOOGLE”的设置使所有项目成员数量无限制及功能统一化，操作简单，不完全依赖相关的软件进行项目的更新。所有“Project owners”拥有相同的权限（因为我只申请了2个GMAIL帐号，同时测试并都配置为Project owners两者都拥有删除项目功能，管理员帐号异常强大未敢尝试）。成员可以有限制的上报信息。这要求志愿者们有高度的责任心和一定的在线时间。
http://code.google.com/p/boinccndoc/
http://code.google.com/p/equn/（为了使项目集中，建议使用EQUN）
这样可以无成本的搭配论坛原有的WIKI功能进行管理组织工作。

欢迎批评指正。

感谢EQUN上的广大志愿者们，和所有支持此项目的人。

duligavin

一楼更新用了
--------------------------------
--------------------------------
2008-6-29
谢谢大家的发言.我还是个小学生,前两天浏览了翻译区的帖子,昨天下午完成了第一篇稿子.昨晚我又继续构思了一下实施BUG管理的意义.

这篇算是对第一篇稿子的补充说明了.

早上看完了至9楼的回帖.

对于个别同志不懂,不清楚的情况,我很抱歉,还没完全构思好就发表了第一篇文章.我平时和EQUN论坛交流不多,大家的水平我还不十分了解.

首先很荣幸的介绍:"BUG跟踪"正是一种可以使文章发布管理变得轻松的方法,理论上说可以达到一劳永逸.

目的:
实现BUG跟踪是为了减轻管理员的管理负担,把管理者从管理工作中解脱出来,高效率利用自己的时间使之用于具体项目中去.

问题:
http://www.equn.com/forum/viewthread.php?tid=18481
我在搜索"版规".而这个帖子中反映出咱们论坛版规制度上的瑕疵.也就说是现在还没有版规.

新手加入,没有版规.不管如何,统一版规或是说契约还是必要的.这是个人信用的基石.

这一现象正是由于论坛缺乏管理才会产生的情况.而新志愿者的加入数量不够多,这缺乏版规的问题所造成的后果没有完全的暴露出来.

什么后果?这个后果就是大家还在为一个可以从一开始制定版规,就能摆平的问题分心,翻旧帖是新志愿者参与的过程,不应该过多干涉,这样会在一定程度上阻碍新事物发展.

无版规本身就是一个BUG.

方向:
从这里开始介绍的就要实行所谓的BUG流程跟踪了.

1.进行翻译工作遵循的规则(众多版规中的一个,也不完全是版规.只是一个翻译工作流程的介绍)

(1)翻译区的发布状态:
-所有已翻译的文章,整理并打包上传服务器.
   -服务器上于干目录上划分一个1级支目录"@1"(内容:1.所有实施分布式计算的网站,2.版规);

   -每一个"@1"下面再分2级支目录@2(包括:1.新闻贴,2.静态贴,WIKI贴或技术贴等);

   -支目录"@2",在这里保存所有文章的最新状态.而且是处于正规状态(或者也可以说发布状态或其他意

思,总之是开放给大众的,这里也可挑错,但影响视图).
   -支目录"@1"用于提供给其它英语官方网站下载中文.
(2)待译区的待译状态:

   - 干目录
        -待译文章在此处认领,察看待译文章的进度.译闭文章留底,留待会员更新查BUG.提交审核.


所有翻译任务可在工作区中进行, 这样的BUG跟踪,是一个无限的循环系统,界面良好.细节尚待讨论


2.由于BOINC的官方性,管理员需要相当慎重的发布信息.而我们需要大量挖掘潜在的志愿者,把文章翻译出来.不开放注册的WIKI无法满足此要求.

漂亮的WIKI最大不足就是无法及时进行BUG跟踪,这样也就无法满足一个分布式多线程的项目进行系统的同步开发.

管理上,前期需要将文章导入至BUG数据库,这是由一定工作量的,而且所有工作都要先从BUG数据库开始.后期导入WIKI就是直接提取数据了.

总结:
有一种特殊情况:可以不更新BUG而直接修改WIKI.这样就抛弃了前期所有的BUG跟踪工作.

那么为了一时方便就直接改WIKI得了吧?或者说我们只用WIKI?

不行.负责人的个人因素无法确定,WIKI会面临无法进行持续更新的情况.但由于WIKI本身的后期内容开放性,不足以使我想说明的问题暴露出来.

WIKI没有发布BUG的跟踪体系,更应该说是没有一种基于流程的跟踪体系.
WIKI也就是表(其中的察看更改历史功能只是后期发布工作的一部分,带来了后期的管理方便而已).
里则需要BUG管理全部的工作状态(也就是从前期开始 就实施全程跟踪,这个地方理解上有点绕弯),

真正的问题:实际上两者不是一回事.
BUG全程跟踪:是可以实现多个负责人同时进行工作的基础.大家不必为分配工作等管理问题操心,自然而然的实现了任务分配.

只要是有能力的人可以自行直接提交任务,
管理员审核后可以直接提交WIKI.
以后的任务自然又回归到BUG跟踪上来.

这样的流程体系升华了管理员需要自己维护BUG(也就是说管理员编写资料,发布资料的WIKI状态).

发展到志愿者提交BUG(减轻了管理员处理杂务的负担,管理员可以专心于自己的工作的这样一种流程状态)成为一种容易实现的过程.  

管理员再也不必为管理所有的项目而担忧,不会因管理上遇到问题而使工作进展缓慢或造成耽误本职工作.

这种开发方法广泛应用于软件生命周期的开发过程,效果很好,国内应用正处于起步阶段.

而作为一种开发工具应用于协同翻译的项目组织管理,也是可行的.

这里提出一些建议:
需要采用事前管理的态度来实现目的. 从一开始就要规范化管理.目前所有项目可以说需要无数的"眼睛"关注BUG,更新BUG更容易.

管理任务也会轻松起来,但也不是这么容易说的清的.不过我该吃饭了.

再次谢谢大家! 2008-6-29 12:00

=======
最新内容时间 :2008-6-29 12:36
版权信息:不经本人同意,一律禁止.


=======
更新内容 2008-6-20-9 16:39

目前查询 关键词"CN"的GOOGLECODE项目不到200个."CHINA"的不到100个.

http://code.google.com/p/equn/
愿意尝试的朋友需要有GMAIL帐号,而且需要现经过我验证才能加入.
请把您的Gmail帐号告诉我.(请发论坛消息)添加Project owners或Project

members.
审核后我会尽快添加您的帐户到相应的权限下.我再发论坛消息通知您后就可以用Gmail登陆.
发放规则是:本论坛的管理员拥有Project owners;
                            会员拥有Project members;
提醒您:使用过程中可能还要用到相关软件进行BUG库的操作.

下面收集了部分可供学习参考的链接地址.
About SetiBoincInf
http://code.google.com/p/setiboincinf/
(用中国关键词)
南京大学天文系
http://code.google.com/p/astrodynamics/
CodeIgniter中国
http://code.google.com/p/codeigniterchina/
中文Squeak(land)
http://code.google.com/p/chinesesqueak/

(用china关键词)
ICanPay
http://code.google.com/p/icanpay/
easyMule
http://code.google.com/p/easymule/
yeeyan
http://code.google.com/p/yeeyan/

周蟒是針對華文地區，以簡化程式教學為主要目的的 Python 程式語言方言
http://code.google.com/p/zhpy

(用cn关键词)
launchy2 中文修改版
http://code.google.com/p/bugzilla-cn/

欢迎访问Bugzilla简体中文本地化开源项目网站
http://code.google.com/p/launchy-chinese/

关于 WordPress 中文团队
http://code.google.com/p/wpcn/

Cyask是一个简单易用的问答系统
http://code.google.com/p/cyaskuc/

Open Book Project 开放图书计划
http://code.google.com/p/openbookproject/

我们的目标是把django文档翻译成中文
http://code.google.com/p/djangodoccn/

GMLive并不直接提供P2P直播服务
http://code.google.com/p/gmlive/

聚合国内python人的力量，建立一整套python的中文本地化工具包
http://code.google.com/p/pyzh/

j(java) w (web) s (studio)是一个集成、绿色、简洁的开发环境
http://code.google.com/p/jws-jpt/

1stlog
http://code.google.com/p/1stlog/

基于Ruby on Rail的SCM(软件配置管理）WEB应用
http://code.google.com/p/rails4scm/

这是一个小型的项目开发管理
http://code.google.com/p/devemanage/

emlog 建筑工地
http://code.google.com/p/emlog/

[ 本帖最后由 duligavin 于 2008-6-29 18:56 编辑 ]

Tynox

楼主也发现目前网站正存在的问题,很高明.

对这种东西我不是很了解.
不过可以告诉楼主,我们的新wiki系统使用的正是"MEDIAWIKI".只是新wiki系统还在测试和完善,所以并没有对所有用户开放.
如果楼主有兴趣一起建设网站的新wiki系统,可以请求EQUN发放测试帐号.

老冬腌菜

不过我感觉 trac 更方便……

Tynox

对这种东西不是很了解啊.
感觉MEDIAWIKI在布局上不错啊,挺美观的.至少我们的新wiki系统是这样子.

[ 本帖最后由 Tynox 于 2008-6-28 19:16 编辑 ]

老冬腌菜

trac 的跟踪系统似乎比较完善……

Youth

嗯，现在我们网站的一个主要问题就是管理资源不足，现在引入wiki的目的也是为了更好地维护主站的资源，楼主的帖子我回头再仔细看看：）

Youth

对trac的实际使用经验不多（也包括google code中的类似的its系统），但觉得还是不适合我们这目前的情况，主要还是我上面说的，管理维护能力不足。

现在的构想是将网站分为wiki和论坛两部分，论坛管理相对简单些，wiki的建设现也算是在摸索中，再多一块内容的话，管理维护上可能更会显得捉襟见肘，所以我现在还是觉得应该先着重把wiki先建设好，其实wiki相对着原来只能由管理员维护的静态页面已经是进步很多了。

具体的几个问题：

1. 链接无效，可以考虑建一个相关的报错帖，专门收集此类信息
2. 更新，主站方面通过wiki应该比较好解决，论坛这边依情况而定吧
3. 嗯，术语这个问题在wiki上特别重要，是得好好处理一下
4. 同样希望通过wiki来解决，毕竟不是只有管理员才能更新页面了
5. 同样wiki....

非常感谢楼主整理的建议，不管是不是都能在短期内采用到：）

碧城仙

我仔细地核查了你所给出的每一个链接。我想你很认真地阅读了我们翻译区所有的帖子。你的建议，很直接的文字，谢谢。很感谢你的阅读，那些被我们所遗忘的。

先对楼主予以 +30 的积分奖励。再对第 1、2 条做一下说明。第 3、4、5 条是我工作失职，我们急需熟悉网页编辑并且有时间愿意帮忙汉化网页的同好。

http://boinc.equn.com/dev/myers.html
该页面是能够打开的，页面中提到的 http://noether.vassar.edu/pub/myers/src/ 链接确实无法打开，我查看了原始网页地址 http://boinc.berkeley.edu/myers.txt 中所提到的该链接地址未更新，确实无法打开。

http://www.equn.com/forum/thread-12434-1-1.html
该帖子里所有链接均可正常访问。

http://www.equn.com/forum/thread-4206-1-5.html
该帖内链接 http://ben.skyiv.com/test/GIMPS/math.htm 是原 ben 斑竹的个人空间内的页面，已经转至本站 http://www.equn.com/gimps/math.htm 页面，原页面链接现在是否能打开已关系不大。

http://www.equn.com/copyright.htm
该页面几经修改，存在过相当长的一段时间，关于本网站是否需要版权保护声明以及版权保护对网友转载推广分布式是否有利一直存在分歧。后来删了，就暂时搁置了。

http://www.equn.com/eon/
原网站 http://eon.cm.utexas.edu/ 首页新闻两年来只增加了 4 条，看来官方网站更新也并不勤快。原网站增加了 1 个新的页面 http://eon.cm.utexas.edu/calculations.php ，该页面内有 JAVA 虚拟机运行程序，移至本站中文子站内来有些困难。

http://www.equn.com/forum/thread-14031-1-2.html
该帖内提及的 http://www.equn.com/3x+1/ 早已全部翻译完毕，时间应该是在 fwj 发的第二个帖子的发帖时间的前一周。小项目，担心无人关注，很低调地没有最后强调其他页面已经上传到本站服务器。另，首页新闻有待追进更新。

碧城仙

我明白你说的东西好，可发展的瓶颈在于人手太少，而不是是否采用了先进的管理模式。
相信论坛里有相当部分的人都有尝试 http://code.google.com/p/equn/ 的能力和实力，我们也希望多些朋友过去尝试，那边的管理员不要局限于我们这边的几位版主，大家都可以去尝试尝试。

duligavin

已添加!短信已发!

相信以后人少的问题会得以解决的!

我非常热烈欢迎大家.决不会有局限的,只要管理员够多,大家可以自己添加新成员权限.

duligavin

透露一个消息code.google.com/p/  可以自己建立项目一个账户7个.

保护EQUN资源啊,多注册相关项目.GOOGLE没意见的.

还要补充2楼关于发放帐号 联系我请采用论坛内短消息

但是要看到GOOGLECODE 的不足.我还在查资料.

[ 本帖最后由 duligavin 于 2008-6-29 23:45 编辑 ]

duligavin

增加参考资料 2007-7-1
-------------------------
表态:
不完全是为提高管理水平而使用新技术;
不完全是因管理员的管理水平不足;
不完全是因人数多少,
为的是人性化;
为的是提高管理水平;
为的是理解一种协作方法,目前旨在探讨如何提高我们翻译等各种工作的效率;

关键词: 跟踪 测试 循环 实践
TAG   : FIX BUG DAS TTD XP DOC QA KEY OPEN

今天,我找到了一些经过理论化了的项目.希望可以使<BUG跟踪应用于翻译,管理>的陋见更系统化.

这些中文中文资料大部分是直译文章资料.
全部来源于Robert C.Martin.
http://www.objectmentor.com/omTeam/martin_r.html

请慎重阅读:有的朋友可能无法立刻理解引文与我观点的意思.不久的将来我会继续更新内容,谢谢大家.

1.面向对象设计的11原则--你称得上OO专家么？ （原文最终修订于2006-04-10 下午06:19:40）
软件文档--扬弃还是传承
http://blog.csdn.net/rmartin/archive/2006/09/26/1287946.aspx

2.软件文档--扬弃还是传承 （原文最终修订于 2006-04-12，上午12:41:14）
赛门铁克公司的极限之旅
http://blog.csdn.net/rmartin/archive/2006/09/12/1213501.aspx

3.性能调优--永远超乎想象 （原文最终修订于 2006-08-28 晚上11：48：38）
软件分析 Vs. 架构设计 （原文最终修订于 2006-05-29 下午06：44：14）
http://blog.csdn.net/rmartin/archive/2006/08/24/1112821.aspx

4.结对编程的成熟度模型 （原文最终修订于 2006-10-08 上午10:52:35）
敏捷的底线
http://blog.csdn.net/rmartin/archive/2006/10/11/1330364.aspx

5.软体艺术系列--抽象工厂 （原文最终修订于2006年10月18日 凌晨04:25:06）
结对编程的成熟度模型 （原文最终修订于 2006-10-08 上午10:52:35）
http://blog.csdn.net/rmartin/archive/2006/10/16/1336367.aspx

6.容器外的JSP页面测试技术
SOA归根到底是什么？
http://blog.csdn.net/rmartin/archive/2007/04/18/1569456.aspx


国内大型应用:
1.www.transn.com

[ 本帖最后由 duligavin 于 2008-7-1 14:58 编辑 ]

duligavin

Max upload size: 20.0 MB.             Using 99 MB out of 100 MB

经测试  http://code.google.com/p/boinccndoc/
56字节 的文件无法上传了,


而1.2M的文档  在issues Commit Log preview功能都可以使用.


刚才显示有其他用户改相同界面,没有保存1.2M文档到服务器.修改WIKI 时出现一些问题
过几秒再次尝试,出现提示:
Page Name:  PageName  

的确没有写NAME

但是似乎有个BUG 无法添加PageName 了
1.2M的WIKI文档无法保存,出现过500等错误.尝试1.2M的WIKI 无法完成

但是Issue可以提交1.2M的文档.Add a Comment and Make Changes也可以提交1.2M的文档

看来除了下载文件100M限制外 其他功能很宽松.WIKI 功能可能不完善.
http://code.google.com/p/boinccndoc/downloads/list
   Filename Summary +                  Labels Uploaded                                      Size   DownloadCount ...
boinc_6.3.2_windows_intelx86.exe  boinc_6.3.2_windows_intelx86.exe   boinc  2 days ago 6.8 MB 0

目前实际的上传限制20M
http://code.google.com/p/boinccndoc/downloads/entry
Max upload size: 20.0 MB.             Using 6.8 MB out of 100 MB

存在配额的限制;
---------------------
新增内容 2008-7-1

要求GOOGLE增加配额,GOOGLEADMIN暂无回复.
http://code.google.com/p/support ... p;can=2&id=1216

[ 本帖最后由 duligavin 于 2008-7-1 14:15 编辑 ]

duligavin

经典问题整理
1.关于开源

(1)Comment by nasserdw, Sep 21, 2007
Can i deny access to my project? i just want certain perople to read or wite on the code??

Comment by jrobbins, Sep 21, 2007
nasserdw: We only host open source projects. That means that anyone can always read your code.
Only project owners or members can write changes to your code.
http://code.google.com/p/support/wiki/WhatsNew


2.关于翻译

(1)Translate Google Code Hosting into other languages

Comment 2 by jrobbins, Jan 16, 2008 Translation is not at odds with our minimalistic philosophy.  It needs to be done, it
is just a question of when.
http://code.google.com/p/support/wiki/WhatsNew

3.关于未来

(1)Proper Pagination  

The number of items shown on each page is now 100.  That means that there are now farfewer pages to flip through.  
So, I'm defering the remaining suggestions in thisissue to a later milestone.
http://code.google.com/p/support/issues/detail?id=102

(2)Feature Request
Comment 1 by jrobbins, Jun 24 (5 days ago) We will not be adding a separate tab, but I agree that sometimes there is a need tomake it easier to manage different issue types. Other times, you really want to seeall issues organize by milestone, or by owner.
Right now, you can query for type:defect or type:enhancement.  You can also use thegrid view and make Type the attribute that defines the columns. Once you get a listor grid view that you like, you can bookmark it or link to it.
Also, right now, you can make it easier for your users to enter an enhancement (orany other particular type of issue that you care about) by using a deep link to theissue entry page.  E.g.,
/p/PROJECT/issues/entry?labels=Type-Enhancement&comment=What%20is%20your%20wish?

I'll keep this issue open for now because I have a change in mind that I think will
satisfy this request more fully.
http://code.google.com/p/support/issues/detail?id=1188

(3)artifact search does not work in projects with two one-letter words in name
Comment 1 by jrobbins, Yesterday (31 hours ago) I can reproduce this in your project. It looks like this bug only affects projectsthat contain two single-character words in their name.  This is probably triggeringstopword behavior in the search engine.One work-around would be to start a new project with a different name, but that isnot very acceptable.  So, I am marking this high priority.
http://code.google.com/p/support/issues/detail?id=1212

[ 本帖最后由 duligavin 于 2008-6-30 10:46 编辑 ]