[JIRA][Bugzilla][HttpClient] should I stay or should I go?
I sent the message below to [EMAIL PROTECTED] and [EMAIL PROTECTED] a week ago following a rather animated discussion on this list about prospects of Jakarta Commons wholesale migration to JIRA. Apparently our infrastructure people have enough on their plates these days, so I can't blame them for being unable to respond. I felt that some of our questions could be answered here. If this is not the appropriate venue to discuss JIRA vs Bugzilla issue, I'd appreciate any pointer as to where I should turn next -- Original message dated Thu 22/01/2004 21:28 Good day, Following the proposal to migrate Jakarta Commons projects from Bugzilla to JIRA posted to the Jakarta commons-dev list, we would like to have a few points clarified, before the final decision can be made whether Jakarta Commons HttpClient project stays with Bugzilla or migrates (kindly requests to be migrated) to JIRA. * Do you actually encourage migration from Bugzilla to JIRA? Will it make the task of to administering and supporting projects' infrastructure (issue tracking in the first place) easier for you? * Can existing bug reports (including closed ones) be migrated to JIRA in their entirety, if at all? What kind of data would not be migrated automatically? Would existing user accounts be preserved? * We (HttpClient committers contributors) have been in fact quite satisfied with Bugzilla so far. It has served us well. The only thing we have found constraining is the release management (versions, milestones, etc). As an alternative to migration to JIRA would it be possible to promote HttpClient from a component of Jakarta-commons project to a full fledged top level project with its own set of versions and milestones? HttpClient has already got its own mailing list. HttpClient related content constitutes 20-30% Bugzilla entries for the Jakarta-commons project. I believe this might be the best option, as least as far as we are concerned. I am just not sure it is technically feasible. Cheers, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JIRA][Bugzilla][HttpClient] should I stay or should I go?
Oleg, Sorry, I thought many of these points were addressed in the general discussion about commons and JIRA. I will respond specifically to each of your questions below... [EMAIL PROTECTED] wrote: * Do you actually encourage migration from Bugzilla to JIRA? Will it make the task of to administering and supporting projects' infrastructure (issue tracking in the first place) easier for you? No, we will not encourage. * Can existing bug reports (including closed ones) be migrated to JIRA in their entirety, if at all? What kind of data would not be migrated automatically? Would existing user accounts be preserved? Yes, existing bug reports can be transfered in their entirety. There is a data migration process. All accounts would also be preserved, although after the conversion, if you change your password in one place (JIRA or bugzilla), it won't change in the other. * We (HttpClient committers contributors) have been in fact quite satisfied with Bugzilla so far. It has served us well. The only thing we have found constraining is the release management (versions, milestones, etc). Agreed, release management is really the kicker for why I wanted it for the James project and why I've been (slowly) getting JIRA running. As an alternative to migration to JIRA would it be possible to promote HttpClient from a component of Jakarta-commons project to a full fledged top level project with its own set of versions and milestones? HttpClient has already got its own mailing list. HttpClient related content constitutes 20-30% Bugzilla entries for the Jakarta-commons project. I believe this might be the best option, as least as far as we are concerned. I am just not sure it is technically feasible. I don't know who or if anybody maintains the bugzilla info. I would send just this request to the infrastructure mailing list and hopefully someone can help. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]