On Mon, Aug 15, 2011 at 1:27 PM, Donald Whytock <dwhyt...@gmail.com> wrote: > 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? >
Rafael has described a plan here: https://cwiki.apache.org/confluence/display/OOOUSERS/Bugtracking+migration > On Mon, Aug 15, 2011 at 9:09 AM, Rob Weir <apa...@robweir.com> wrote: >> On Mon, Aug 15, 2011 at 12:52 AM, Dennis E. Hamilton >> <dennis.hamil...@acm.org> 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:apa...@robweir.com] >>> Sent: Sunday, August 14, 2011 06:03 >>> To: ooo-dev@incubator.apache.org >>> 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 >>> <dennis.hamil...@acm.org> 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:apa...@robweir.com] >>>> Sent: Saturday, August 13, 2011 18:45 >>>> To: ooo-dev@incubator.apache.org >>>> 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 >>>> <dennis.hamil...@acm.org> 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:gst...@gmail.com] >>>>> Sent: Thursday, June 30, 2011 16:05 >>>>> To: ooo-dev@incubator.apache.org >>>>> Subject: Re: Speaking of JIRA, Where's Ours? >>>>> >>>>> On Thu, Jun 30, 2011 at 12:54, Rob Weir <apa...@robweir.com> wrote: >>>>>> On Thu, Jun 30, 2011 at 12:12 PM, Alexandro Colorado >>>>>> <j...@openoffice.org> 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 >>>>> >>>>> >>>> >>>> >>> >>> >> >
