On Thu, Jun 30, 2011 at 12:54, Rob Weir <[email protected]> wrote: > On Thu, Jun 30, 2011 at 12:12 PM, Alexandro Colorado <[email protected]> > wrote: >> On Thu, Jun 30, 2011 at 10:53 AM, Rob Weir <[email protected]> wrote: >> >>> I'd like to reopen this question,since I haven't seen a resolution. >>> >>> I'm hearing some proposing Bugzilla, because of familiarity and ease >>> of migration. >>> >>> I'm also hearing some say that JIRA is superior. >>> >>> I'm not really persuaded by either argument. I wonder if we could >>> briefly drill down into this a bit more. >>> >>> 1) I read that the OOo bugzilla has been customized. Can anyone >>> explain the nature of the customizations? >>> >>> 2) In what sense if JIRA better? IMHO all defect tracking systems >>> suck. But I'm open to the possibility that some suck less. >>> >>> 3) On migration, would it be reasonable to attempt a sandboxed trial >>> migration of Bugzilla to JIRA, and let skeptics poke at it for a >>> while, to see if, for example, IDs are preserved, etc.? Would that be >>> much work? The easiest way to convince people that JIRA is possible >>> and reasonable might be to actually do it. >>> >>> 4) What are the downsides of Bugzilla? If it is a supported option at >>> Apache, wouldn't that be the obvious choice? I think we'd need to >>> make a good case for why an alternative would be better. What are, >>> say, the top 3 things that JIRA would do better than Bugzilla? >>> >> >> I can argually say that both suck, the issue tracker that I have seen >> easiest is the one provided by google code. >> >> The problem with that tracker is that I am not sure is doable for larger >> projects.
The Chromium project uses Google Code's tracker[1]. They're over 88,000 bugs now and going. >> The biggest hump of using an issue tracker is locating the right people >> (subcomponent) to get the issue to, or asigning a developer to it. whcih >> most times is not aparent. The previous OOo (Collabnet) supported templates >> which fill out your issue tracker in order to submit the issues faster. >> However I found not many people really used it. >> > > There are two audiences (at least) for the tracker: > > 1) Project members, who know their way around, know the sub components, etc. > > 2) Users, or other who submit a defect report rarely. They need an > easy way to enter a bug report and check its status later. Totally agree. And that was the basis of my design for the Google Code tracker. I wanted it real easy for the users to submit a bug, and possibly attach stuff. They only need a short description, and then details. Users know *nothing* about subcomponents, assignees, milestones, whatever. The developers would then triage the new bugs and apply the correct tags. Jason Robbins built the tracker using those key principles, and I think it turned out very well. Of course, I'm biased. But still :-) If we wanted to use it, then we could fire up a project on apache-extras.org and use it. We can use its API to import all the old bugs. >... > And what if we didn't assign developers at all? What if instead we > had project volunteers claim what issues they want to work on and > self-assign them? I'd prefer this approach. It is generally best to view the bugs as owned by the community. That you don't have "one developer" assigned to a component. And that anybody can grab a bug and start working. >... Cheers, -g [1] http://code.google.com/p/chromium/issues/list
