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
