incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
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 <apache@robweir.com> wrote:
> On Thu, Jun 30, 2011 at 12:12 PM, Alexandro Colorado <jza@openoffice.org> wrote:
>> On Thu, Jun 30, 2011 at 10:53 AM, Rob Weir <apache@robweir.com> 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

Mime
View raw message