Hi, 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 > 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. (*)
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': http://issues.apache.org/jira/secure/QuickSearch.jspa?searchString=%s 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: http://issues.apache.org/jira/browse/HIVEMIND-103?page=all http://issues.apache.org/jira/browse/JAMES-253?page=all http://issues.apache.org/jira/browse/FOR-528?page=all The actual links are broken at the moment - see http://issues.apache.org/jira/browse/INFRA-354 (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 '[EMAIL PROTECTED]'). 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' everywhere. - Once infra@ people get to it, it WILL be possible to reply to email, and have the reply added as a comment (see http://issues.apache.org/jira/browse/INFRA-412). 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 http://jira.atlassian.com/browse/JRA-1560 7) Not OSS JIRA is written by ruthless hippie-bashing capitalists. -o0o- 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. --Jeff > >> 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
