> My suggestion would be to also investigate the possibility of HttpClient > being promoted (in Bugzilla only) to a "project" rather than a component > of commons, and also see about having the Bugzilla version updated.
Eric, I think it's a brilliant idea. It does make sense that HttpClient gets treated slightly differently than other peer Commons sub-projects due to a higher volume of bug reports/feature requests we get. Out of 100 some open bug reports in Jakarta-Commons project 30 some are ours. When first 3.0-alpha comes out, this number is quite likely to increase substantially. Unfortunately, I do know how difficult that would be (if technically feasible at all). > As > it is, it seems unfair to compare to JIRA with respect to this > issue, because migrating to JIRA will apparently make HttpClient a > "top" level project- thus comparing apples to oranges. I believe JIRA can assign a unique versioning scheme on a per component (in Bugzilla parlance sub-project) basis. But you have a point here, anyways. Oleg -----Original Message----- From: Eric Johnson [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 18:09 To: Commons HttpClient Project Subject: Re: JIRA vs Bugzilla issue Well, I'm not sure how I would recommend going on this decision. So here is my attempt at providing a slightly biased (in favor of Bugzilla) view of the facts. I looked at nagoya.apache.org, and checked out both the Scarab and Jelly installations running there. Random observations: * Bugzilla is designed for a "flat" product listing. Currently Apache Commons tools are listed as a component of Apache Commons, rather than a top-level project like "Commons-HttpClient". Were this changed instead, all of the complaints about not being able to establish coherent milestones and versions would go away. As it is, it seems unfair to compare to JIRA with respect to this issue, because migrating to JIRA will apparently make HttpClient a "top" level project- thus comparing apples to oranges. * Apache appears to be running Bugzilla 2.14.2. Bugzilla is up to 2.16.4 for their stable build, and 2.17.6 on their testing branch. We use 2.16.4 at my office and I have no complaints with it. I know that there are some nice but subtle improvements with the newer release(s). * JIRA appears to be missing a nice feature of (the newer) Bugzilla, namely that when examining a bug from a list of bugs, you can click Next and Previous to see other bugs, rather than having to go back to the list view. In Mozilla, this actually enables an extra toolbar with next and previous buttons. * JIRA has a significantly cleaner look and feel, most definitely. * JIRA appears to have links to specific responses to issues/bugs. Bugzilla doesn't have this - you can only link to the bug as a whole, so far as I know. * Scarab doesn't let an unregister user browse the reports. This pretty much shoots it down for use in a open source project, for me. I wonder if that is just the way that Apache has it configured. * Scarab appears to be much stricter about its access controls. I'm not sure whether the extra refinement just gets in the way. * As far as the notification emails that JIRA sends out versus the ones that Bugzilla sends, I like the ones that Bugzilla sends better. Far more compact (again a configuration issue?) My suggestion would be to also investigate the possibility of HttpClient being promoted (in Bugzilla only) to a "project" rather than a component of commons, and also see about having the Bugzilla version updated. -Eric. Kalnichevski, Oleg wrote: >>Is there an automatic way to move the current issues over to JIRA? The open >>bugs are important, but the closed ones also contain a wealth of >>information. >> >> > >I do not have all the details, but JIRA is believed to provide some sort of an >automated migration path for existing Bugzilla installations. Anyways, if ALL >existing bug reports cannot be retained, in my opinion, that would completely defeat >the whole migration idea. > >I'll double-check the possibility of having existing reports migrated with the >infrastructure folks, before the final decision is made. > >I'll keep you posted. > >Oleg > >-----Original Message----- >From: Rezaei, Mohammad A. [mailto:[EMAIL PROTECTED] >Sent: Wednesday, January 21, 2004 15:24 >To: 'Commons HttpClient Project' >Subject: RE: JIRA vs Bugzilla issue > > >Is there an automatic way to move the current issues over to JIRA? The open >bugs are important, but the closed ones also contain a wealth of >information. > >Thanks >Moh > >-----Original Message----- >From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] >Sent: Wednesday, January 21, 2004 6:41 AM >To: Jakarta Commons HttpClient mailing list >Subject: Re: JIRA vs Bugzilla issue > > >Folks, >What say you, do we migrate HttpClient issue tracking to JIRA or do we stay >with Bugzilla? Please let me know your opinion. > >Oleg > > >On Tue, 2004-01-13 at 20:29, Oleg Kalnichevski wrote: > > >>Shall I apply? Any strong opinions to not migrate to JIRA? >> >>Oleg >> >> >>On Tue, 2004-01-13 at 20:01, Michael Becke wrote: >> >> >>>Yes, I've been following that discussion as well. I'm definitely >>>interested in making the switch to JIRA. Bugzilla has served us pretty >>>well, but I find it somewhat unwieldy at times. >>> >>>Mike >>> >>>On Jan 13, 2004, at 11:44 AM, Kalnichevski, Oleg wrote: >>> >>> >>> >>>>There's currently a rather animated discussion 'JIRA vs Bugzilla' >>>>going on the commons-dev mailing list. Personally I do not have a >>>>strong option on this issue. There's one thing, though, that makes me >>>>bring it up here: we are facing the need to massively restructure >>>>Bugzilla content related to HttpClient due to the change of the next >>>>release version from 2.1 to 3.0. (Funny enough, the way versioning is >>>>handled in Bugzilla is being one of the most frequently mentioned >>>>motivators for migration to JIRA). My point here, if we ever wanted to >>>> >>>> > > > >>>>migrate to JIRA, now would be the right moment. >>>> >>>>Let me know what you think (let us not turn it into a religious >>>>war >>>>currently being waged on the commons-dev, though) >>>> >>>>Oleg >>>> >>>>------------------------------------------------------------------ >>>>--- >>>>To unsubscribe, e-mail: >>>>[EMAIL PROTECTED] >>>>For additional commands, e-mail: >>>>[EMAIL PROTECTED] >>>> >>>> >>>> >>>-------------------------------------------------------------------- >>>- >>>To unsubscribe, e-mail: >>> >>> >[EMAIL PROTECTED] > > >>>For additional commands, e-mail: >>> >>> >[EMAIL PROTECTED] > > >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: >>[EMAIL PROTECTED] >>For additional commands, e-mail: >> >> >[EMAIL PROTECTED] > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: >[EMAIL PROTECTED] >For additional commands, e-mail: >[EMAIL PROTECTED] > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
