On 13 Sep 2005, at 16:40, Vadim Gritsenko wrote:
Pier Fumagalli wrote:On 13 Sep 2005, at 15:25, Vadim Gritsenko wrote: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-188No '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.
Nonono... That's a problem with permissions. Are you a committer to Jackrabbit? Have the Jackrabbit group given permissions to any logged in users to fiddle about with their bugs? Or are people not in the Jackrabbit group only allowed to further comment on issues, but not (for example) to modify their status?
That's all up to the configuration for each individual project.
IMNSHO, it's a deal breaker if our own users can't mess with our own bug database. (*)
I would be against to have anyone who logged in to completely whack the status of any bug in the DB, but if that is desirable for Cocoon, it can be done with a simple configuration of the policies associated with the Cocoon project.
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).Constructive comment would be; * What it does better?So is this stuff configured at issues.apache.org too?
I don't know... It simply would entail a simple copy of a file in the JIRA WEB-INF/lib directory and a quick restart. Nothing major in terms of setup (Took me no more than 2 minutes on our local Jira installation).
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 :)
Not really... Cocoon, for example, has quite a different setup from all the other projects and I can see aspects for which certain fields might be introduced only for us. For example, something that defines if the bug is encountered in the "XCONF" "SAMPLES" "JAVA" or "MOCKS" part of a "BLOCK" (kinda like subcomponent).
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.
It's restrictive for when someone wants to track status on complex bugs... Especially for blocks (and even more when we'll have real blocks) I can see a situation in which the dependancy tree might have to be extended to cover other variations of relationship... But that's me.
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.
I bet it's unused... Why would you want to enter a version twice? Both in the "Versions" and in the "Milestones"? And as far as I can see, I don't see any reports over them: no, clicking at the bottom to go to the "search", then clicking at the top to go to "advanced search" filling in a page with proably 50 input boxes, and with ALL milestones / versions displayed for ALL project until I don't select "Cocoon 2" is not what I call a usable report :-) (Read, usability at the end, as you said). I prefer my two-clicks on Jira to get to the point! :-P
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 faster?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.
Never experienced that delay (not even on the ASF installation), but I might have hit bugs that were always cached. Or maybe just because from the office we have quite a large pipe going down directly to Holland (VNU is a NL company, and our hosting facility over there is the same as AJAX, the one running issues.apache.org).
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).
As I said, (*) above is probably just because you're not part of a particular group, and that particular group doesn't want other people to fiddle too much with their issues.
Pier
smime.p7s
Description: S/MIME cryptographic signature
