cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: Shall we switch to Jira?
Date Tue, 13 Sep 2005 15:02:38 GMT
On 13 Sep 2005, at 15:25, Vadim Gritsenko wrote:

>>>> and send status of them to a particular  individual / list /   
>>>> email, or to have customized workflows / fields /  schemes and  
>>>> so  on...
>>> We don't need that crap. It is problem enough that half of the  
>>> time  you can't do much in Jira while working with other  
>>> projects, no  need to screw up Cocoon's bug tracking system.
>> In my opinion those are quite nice features... Having to work (by   
>> choice) with Jira at work, I feel personally that some of that   
>> "crap" (once you get used to it, and start _really_ working with   
>> Jira) is _extremely_ useful.
> It's really frustrating when you can't change bug status or do some  
> other tasks. That's what I meant; I presume that's part of  
> 'customized workflows' feature. Yep, I had bunch of experience with  
> ClearQuest, did not liked it either.

You can't change the bug status? That's really freaky. The status as  
in "open", "resolved", "closed" ... ?
There are normally big buttons on the left of the UI that depending  
on the current status of an issue, allow you to move to the next  
ones: for example if a bug is "open" you have links to "close" and  
"resolve and close" on the left, it will ask for an activity comment  
and change the status.

This _can_ be configured with custom workflows but the default one  
works pretty much all right.

>> And since I spend 20% of my time tracking projects at work using   
>> Jira, I think that it might be a good solution also for this  
>> project.  That said, this is my humble opinion, and as the subject  
>> of this mail  states "Shall we switch to Jira", I'm asking for  
>> comments from other  members of this list, _constructive_ comments.
> Constructive comment would be;
>   * What it does better?

Per-user customization is (IMVHO) one of the coolest things in there,  
and the reports integrated in Jira are killer. I personally use it  
also to track and link automagically bugs from Subversion commits  
with the Jira subversion plugin and ViewSVN, so, no more fix a bug in  
SVN, copy and paste the commit message, modify the bug tracking  
database. Jira picks it up automatically (I don't know if Bugzilla  
does the same nowadays).

Every single friggin label (also) is customizable, statuses,  
component, fields, EVERYTHING can be added or removed, so for every  
project/component/issue-type one can have different fields /  
requirements depending on the real needs of the project.

Multiple components per bug. If for example a bug affects more than  
one part of the system (validation block , samples , sitemap  
configuration ) they can all be assigned to the same issue.

Customizable issues linking. Not only "mark as duplicate of this  
bug", but also, this task / bug / xxx requires the resolution of, is  
related to, is a duplicate of, blablabla (customizable).

Version management: not only one can specify in what version one  
found a bug, but also in what version it will be fixed, so that we  
can have clear roadmaps of what has been found in what versions, and  
what was (needs to be) fixed in what version.

>   * Is it faster?

Yes in my particular experience. The search provided by Lucene/Jira  
is faster than the one provided by SQL/BugZilla. It depends (though)  
on how it's installed, how much ram the VM has, and so on and so forth.

As far as I can see, looking for the word "cocoon" in Jira gives me a  
first page of results in roughly one second, on and Bugzilla it takes  
roughly 2.5 (but that might be my internet connection, the specific  
query, blablabla). In other words, my experience.

>   * Is it more stable?

In two years of production use of Jira, I never saw it crash once. I  
believe that the issues related to the stability of Jira on the ASF  
were tied to the use of Tomcat rather than Jetty (what I personally  
use in production). And I believe that those were solved when was moved to AJAX from Nagoya.

> I tried using it, and (IMVHO) it fails on last two points and has  
> hard-to-read-at-a-glance UI.

Agreed, the user interface is far from perfect (and Apache's choice  
of colors makes it even uglier), but IMVO Bugzilla's worse.


View raw message