incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Speaking of JIRA, Where's Ours?
Date Thu, 30 Jun 2011 23:05:02 GMT
On Thu, Jun 30, 2011 at 12:54, Rob Weir <> wrote:
> On Thu, Jun 30, 2011 at 12:12 PM, Alexandro Colorado <> wrote:
>> On Thu, Jun 30, 2011 at 10:53 AM, Rob Weir <> 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 and use it. We can use its API to import all the old

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




View raw message