[Webtest] Bug trackin tool for webtest?

webtest@lists.canoo.com webtest@lists.canoo.com
Wed, 12 Jan 2005 23:15:48 +0100


" Bite the bullet..." 
Just for curiosity:
Do you have already made a choice for the software? 
Kay

> --__--__--
>  From: "Dierk Koenig" <dierk.koenig@canoo.com>
> To: <webtest@lists.canoo.com>
> Subject: RE: [Webtest] Bug trackin tool for webtest?
> Date: Mon, 10 Jan 2005 11:10:53 +0100
> Reply-To: webtest@lists.canoo.com
> 
> Wow! This is a convincing pleading!
> 
> Thanx for your offer to support the installation.
> Unfortunately, our infrastructure is not designed to offer
> webspace that way. It seems I now have to bite the bullet
> and do the installation.
> 
> Anyone who wants to help is asked for keeping the
> _content_ of the BTT (Bug Tracking Tool) as
> concise, up-to-date, and duplication free as possible.
> 
> cheers
> Mittie
> 
> > -----Original Message-----
> > From: webtest-admin@lists.canoo.com
> > [mailto:webtest-admin@lists.canoo.com]On Behalf Of kay@hallo.ms
> > Sent: Samstag, 8. Januar 2005 11:26
> > To: webtest@lists.canoo.com
> > Subject: [Webtest] Bug trackin tool for webtest?
> > 
> > 
> > Hi, 
> > Happy New year!  (getting a bit old already eh? ).
> > And thanks for the great support of webtest to all contributors!
> > 
> > I vote for a bugtracker. 
> > 
> > 1) I think the wiki is not very accessible wh.r.t  bugs since 
> > people have first to get used to the snipsnap wiki dialect. If 
> > you want to communicate a bug, that is not what you are waiting 
> > for. Also I have the impression that among the users of the 
> > webtest wiki there is a lot of confusion on how it is intended to 
> > be used: Who may edit what? And whether to put comments or 
> > directly edit the text for example. Or who is responsible or 
> > entitled to cleanup outdated stuff. (Don't misunderstand, I am 
> > passionate of wiki use in projects.)
> > 2) The wiki may be an innovative and convenient way to 
> > communicate about bugs, but it is a quite unusual one. This 
> > means, that for newcomers, it is not easy to understand its place 
> > and intention in the project. (Especially because there are so 
> > few bugs registered) I asked myself seeing it the first time: Is 
> > this page abandoned? Will someone notice it? Where is the REAL 
> > bug administration?
> > 3) About hosting. If you don't have time to set it up or 
> > administrate it, why not ask for some space on sourceforge or 
> > some other OpenSource host? If you can supply me with webspace at 
> > canoo, I am also willing to set it up for you (e.g. Bugzilla). 
> > 4) I agree about the overkill of features, that often distract 
> > from the task if you want to keep it simple. But most of the time 
> > there is a way to configure the tool in order to limit that. For 
> > example for webtest you could only allow the bugs to be submitted 
> > for one category and with the default priority. Since many tools 
> > are open source simple adjustments to the html page could 
> > eliminate a lot of unused options. Apart from that, once a bug is 
> > inserted in a tracking system, posting comments about it is 
> > normally very straightforward.
> > 5) Definitely, in terms of history and search/query these systems 
> > are better than the wiki. They may even replace in many cases 
> > tedious screening of the mailing lists if you want to know 
> > whether someone had the same problems as you. 
> > 6) A very strong feature of issuetrackers that is not standard 
> > yet but may become so in the near future, is the possible 
> > coupling with the versioning system. This allows for example for 
> > a certain bug to see by one click how the fix was implemented in 
> > the code. Or to link even to a test that proves the fix. I think 
> > this coupling would also be worth considering for the future of 
> > the webtest project.  At the moment the effort required to 
> > implement/configure this is considerable, but with subversion it 
> > should be easier to implement. (You think about moving to 
> > subversion don't you? ).
> > 7) Lisa has a strong argument, that posting issues on the 
> > mailinglist is much more direct and you don't feel the dust of 
> > administration this way.  On the other hand, one could configure 
> > the issueTracker to post to the mailing list too!
> > 
> > 
> > ... its getting a whole book if I continue - sorry.
> > Kay
> >