cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: Shall we switch to Jira?
Date Tue, 13 Sep 2005 16:21:06 GMT
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-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.

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.

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

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

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

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


Mime
View raw message