So...what IS the migrated AOO issue tracker? I believe that was the original question? Since an issue tracker is a migration issue, is it time to decide on this particular migration issue?
On Mon, Aug 15, 2011 at 9:09 AM, Rob Weir <[email protected]> wrote: > On Mon, Aug 15, 2011 at 12:52 AM, Dennis E. Hamilton > <[email protected]> wrote: >> My question is essentially whether there is a choice we could make for an >> issue tracker now that gives us an important tool for managing existing >> project issues without impairing our ability to migrate the OpenOffice.org >> bugzilla when we are ready to do that. >> > > Why not use the existing OOo Bugzilla? I see that others have > opened or modifed 185 issues in OOo Bugzilla in just August 2011. > > http://openoffice.org/bugzilla/ > > That is the general theme of the migration, right? Use existing > support forums until we cut over to their migrated versions. We're > not setting up temporary user forums. Use existing doc wiki until we > cut over to migrated doc wiki. We're not setting up a temporary doc > wiki. Use the existing language projects until we migrate them to > Apache. We're not setting up temporary language projects. Etc, Etc., > Etc. > > Why wouldn't the same be true of reporting defects? > >> I don't understand such systems well enough to make a recommendation. I am >> asking if anyone else has knowledge of one or more approaches that would >> achieve that. >> >> If not, we get to wait until the OpenOffice.org bugzilla is migrated, >> however that is resolved. >> > > Why wait? > >> I don't find wikis an easier alternative. If I had, I would not have raised >> this question. I think I was clear enough on what I consider the advantages >> of issue trackers. >> >> - Dennis >> >> SIDE COMMENTARY >> >> Someone suggested posting patches to the list for various things, and I was >> relating to that with regard to posting patches to an issue tracker where >> they stay visible. I don't have any patches in mind. >> >> I enter bugs in bugzilla reluctantly. I do it when I have to. Perhaps that >> has to do with how the bugzillas I've used are configured. My attention on >> LibreOffice was an accidental choice because I wanted to follow the action >> there at a time when I became more interested in interoperability with >> existing implementations and OpenOffice.org was already in some sort of >> doldrums. It is gratifying to get results on bugs I have reported to >> LibreOffice. I am able to provide support in an immediate way there, and I >> will continue with that satisfying activity also. >> >> When there is an Apache code base and a way to make similar contributions >> here, I will do that here too. I'm not waiting. >> >> -----Original Message----- >> From: Rob Weir [mailto:[email protected]] >> Sent: Sunday, August 14, 2011 06:03 >> To: [email protected] >> Subject: Re: [Issues] [DISCUSS] Can we track Issues Somehow? (was RE: >> Speaking of JIRA, Where's Ours?) >> >> On Sat, Aug 13, 2011 at 11:11 PM, Dennis E. Hamilton >> <[email protected]> wrote: >>> A tracked issue keeps things in one place, it provides a record of open >>> work items and the actions on it are apparently posted to the list. So it >>> is much easier to follow the ones you care about, review them, and so on. >>> It is also a safer place to post patches, feature requests, and so on where >>> they can sit until we are actually ready to do something with them. The >>> record of progressing action is simply different than tracking wiki pages. >>> >> >> You were originally asking about issues related to migration. I don't >> expect that will include many patches, feature requests (at least not >> outside of the list discussions). >> >> If you have other issues of a more general nature, why not just stick >> them in the existing Bugzilla? Nothing there will be lost. It might >> be locked to updates for a day or two during the actual migration. >> But up to that point all issues entered there are slated to be >> eventually migrated to an Apache host. >> >>> I miss having one. We're going to need one, it would be good to figure out >>> how to remove the roadblock involved in worrying how to preserve the >>> OpenOffice.org bugzilla if possible. >>> >> >> That part's easy, at least conceptually. Someone steps up and volunteers. >> >>> I also have no idea how many issues we are missing from public contributors >>> because there is no one to place them. >>> >> >> Don't you think the public would be more familiar with the OOo >> Bugzilla tracker that has been around for years than any new, >> temporary issue tracker that we might set up? If you want, we could >> post a link to the OOo BZ from our home page, for the benefit of those >> who are newly involved with the project. Post-migration, the URL >> should be the same. >> >>> What I do instead, for specifics to the implementations, is post bugs on >>> LibreOffice and use their user list. >>> >> >> So you can do the same for OpenOffice, right? Or is there some >> problem I'm not seeing with this? >> >>> But we have plenty of work items around the migration here, and if we had >>> an issue tracker, I would hope that is more inviting for folks taking on >>> something they see as immediately within their grasp. >>> >> >> I still think for migration-related issues, the mailing list and the >> wiki are the best places. Adding a third place to store such >> information will just scatter the information more than concentrate >> it. If we had used an issue tracker consistently from the start it >> might have been different. But we didn't. >> >>> - Dennis >>> >>> -----Original Message----- >>> From: Rob Weir [mailto:[email protected]] >>> Sent: Saturday, August 13, 2011 18:45 >>> To: [email protected] >>> Subject: Re: [Issues] [DISCUSS] Can we track Issues Somehow? (was RE: >>> Speaking of JIRA, Where's Ours?) >>> >>> On Sat, Aug 13, 2011 at 1:27 PM, Dennis E. Hamilton >>> <[email protected]> wrote: >>>> 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. >>>> >>> >>> Do we? I mean, do we need something more than discussing them in >>> clearly-labeled threads on the mailing list? Or tracking plans on the >>> wiki, as we are doing already? >>> >>>> 2. We don't want to foreclose how we end up finally migrating the >>>> OpenOffice.org 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 started tracking some items on the wiki, as a short term approach. >>> Since there appears to be a great deal of enthusiasm for using the >>> wiki, how about start that way? If we're dealing with a dozen or 2 >>> issues or fewer, then setting up a JIRA or BZ issue is overkill. >>> Remember, we're already tracking planning activities related to the >>> migration on the wiki. It isn't clear that trying to tease action >>> items out of the plans on the wiki and then placing them in JIRA does >>> anything for us. >>> >>> Also, we should avoid the seductive illusion that activity is a >>> substitute for progress. Having volunteers move forward on the code >>> check-ins and on the real Bugzilla migration would be progress. >>> Churning on issue tracking would not. >>> >>>> I'm all for ease-of-use. How can we have a working issue tracker off of >>>> the critical path around migrating the OpenOffice.org 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 later? >>>> >>> >>> Easiest way to avoid the more complex effort is to use the simplest >>> tool that accomplishes the task. The simplest tool right now is the >>> mailing list. Wiki is 2nd. >>> >>>> - Dennis >>>> >>>> -----Original Message----- >>>> From: Greg Stein [mailto:[email protected]] >>>> Sent: Thursday, June 30, 2011 16:05 >>>> To: [email protected] >>>> Subject: Re: Speaking of JIRA, Where's Ours? >>>> >>>> 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: >>>> [ ... ] >>>>>> >>>>>> 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 >>>> >>>> >>> >>> >> >> >
