cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Shall we switch to Jira?
Date Tue, 13 Sep 2005 15:40:00 GMT
Pier Fumagalli wrote:
> On 13 Sep 2005, at 15:25, Vadim Gritsenko wrote:
> 
>> 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.
> 
> You can't change the bug status? That's really freaky. The status as  in 
> "open", "resolved", "closed" ... ?

Yes.

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

Examples
   http://issues.apache.org/jira/browse/JCR-169
   http://issues.apache.org/jira/browse/JCR-188

No 'Close', no 'Reopen', only 'Clone' and some such. And it's not limited to 
JCR. And I'm currently logged in - not an anonymous browsing.

IMNSHO, it's a deal breaker if our own users can't mess with our own bug 
database. (*)


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

So is this stuff configured at issues.apache.org too?


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

That's on one side - on the other each project's jira can be made so different 
that you'll momentarily get lost :) Sounds like FS to me :)


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

That's good.


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

Bugzilla (as I see) has only Depends, Blocks, Duplicate. Not customizable but 
covers many usecases.


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

It seems bugzilla has 'Target Milestone' for this. Not used in Cocoon's bugzilla.


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

Well direct access to the bug usually takes 5-10 secs in jira (unless cached?), 
and 1-5 secs in bugzilla. Advanced search might be faster in jira - dunno.


>>   * 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  
> issues.apache.org 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.

Summarizing above, I don't mind giving it a try as long as (*) above is resolved 
somehow (either throw my education or jira configuration, that's it :-p).

Vadim

Mime
View raw message