cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Jira pros and cons (Re: Shall we switch to Jira?)
Date Wed, 14 Sep 2005 05:07:33 GMT

On Tue, Sep 13, 2005 at 11:40:00AM -0400, Vadim Gritsenko wrote:
> 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.
> Examples
> 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. (*)

It's a permission set in the JCR project (only developers can
resolve/close). IMHO it's disempowering, kills the do-ocracy spirit and
generally sucks. Probably this was not a deliberate choice of the
project. Someone just copied the permissions when setting up JCR. I'll
start a discussion on infra@ about standardizing on a suitably open
permission scheme.

To address some points made (disclaimer: I work for Atlassian):

1) Speed & search useability

Clicking through JIRA does feel slow compared to Bugzilla, but JIRA has a
search mini-language that means you rarely have to. In JIRA you can type
'VELOCITY open NullPointerException' in the quick search bar on every
page, and you'll get back a list of open Velocity bugs mentioning
NullPointerException in the summary/body. Adding 'v:1.5' limits the
Affects version, adding 'ff:1.6' limits the fix-for version. 'my' limits
to issues assigned to you. 'c:' limits to component.

This can be made even faster. In Firefox, try bookmarking the following
URL, and give it the keyword 'asf':

Now you can type 'asf VELOCITY open' in the browser, and go directly to
the search results. You can also jump to an individual bug with 'asf
VELOCITY-374'. With this, you rarely need to use the web search UI or
visit the front page.

2) Subversion integration.

Examples at:

The actual links are broken at the moment - see

(and while you're there, notice the trackback link automatically
established from the Atlassian JIRA:)

3) Decent email support

Given that what most people see from the bug tracker is the emails, I
think this is worth particular attention.

 - In JIRA, email notifications 'thread' in mail clients, so
  comments/updates on an issue can be grouped with the original issue
   creation notification.  When reading a comment you can quickly see the
   previous comment, or the original issue in the thread.

 - The 'From' header includes the name of the changer (not just
   ''). This lets you search/sort for bugs by
   reporter/commenter in your mail client.

 - IMHO the email format is a bit more readable - no 'DO NOT REPLY'

 - Once infra@ people get to it, it WILL be possible to reply to email,
   and have the reply added as a comment (see

4) Linking with other OSS projects

JIRA will increase intertwinglyness with related projects, but allowing
internal links to other projects in the ASF JIRA (Lenya, Forrest, Xalan,
Avalon) and trackback links to external JIRA installations (Daisy,
Hibernate, Codehaus projects).

As for downsides:

5) Stability

The ASF JIRA installation does run out of memory occasionally, and about
once every 2 weeks recently. I suspect it's a leak in the SVN parsing,
which the ASF JIRA does an awful lot of. We're working on addressing this
(see infrastructure@ traffic for details). 

6) Limited search options

The Bugzilla search form is complicated because you can do lots of cool
stuff in it. JIRA's search capabilities are primitive by comparison.
There's no regexp support, and you can't do arbitrary AND/OR/NOT queries.
This will be addressed eventually - see

7) Not OSS

JIRA is written by ruthless hippie-bashing capitalists.


Anyway, I suggest importing the Bugzilla issues into Cocoon to let people
play (I think Pier's an admin).  The importer can be re-run occasionally,
and the permission scheme configured to let only developers create issues
(for testing).  To be honest though, there is no one knock-down
improvement (unless SVN integration counts) - just lots of little ones
that become apparent over time.


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

View raw message