incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject [Issues] [DISCUSS] Can we track Issues Somehow? (was RE: Speaking of JIRA, Where's Ours?)
Date Sat, 13 Aug 2011 17:27:27 GMT
It's been two months since the podling started and we still don't have issue tracking.  

1. We need something for recording and tracking issues now, including ones that are involved
in the migrations we're struggling with.

2. We don't want to foreclose how we end up finally migrating the bug tracker
and all of the history that represents.

I don't know enough to see how to have (1) and (2) both.  Can we choose one quickly for transitional
use, and then merge the OO.o bugs with it or merge it with the OO.o bugs, whichever works?

It looks like three choices have been proposed:

 1. Apache JIRA
 2. Apache bug-tracker
 3. Google Code issue tracker (available on Apache Extras)

I'm all for ease-of-use.  How can we have a working issue tracker off of the critical path
around migrating the bug tracker without getting in the way of that more complex
effort?  Do we have to choose one for the migrated bug tracking now or can we resolve that

 - Dennis

-----Original Message-----
From: Greg Stein [] 
Sent: Thursday, June 30, 2011 16:05
Subject: Re: Speaking of JIRA, Where's Ours?

On Thu, Jun 30, 2011 at 12:54, Rob Weir <> wrote:
> On Thu, Jun 30, 2011 at 12:12 PM, Alexandro Colorado <> wrote:
[ ... ]
>> 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