Hello everyone. This thread is to summarize the discussion, suggestions and concerns surrounding our adoption of JIRA. Hopefully next week we can bring this to a VOTE (if necessary) and submit the request to infrastructure.
= Unanimous Support of Adoption = First, I want to point out that thus far, there has been unanimous support for adopting JIRA. Moreover, we would like to start fresh with JIRA and not worry about importing historic data from Bugzilla. No one has yet posted an objection to these proposal. = JIRA Admins = Aaron Farr, Stephen McConnell, and Noel have been suggested as admins. I would like to add that rather than limit the administrative duties to a few, perhaps all the PMC (if not all committers) be given admin rights. Even if only a couple of us actually perform most admin duties, this more open approach might encourage more participation and would spread out the work. = JIRA Project Organization = There has been quite a bit of discussion about how to organize projects in JIRA. To review, there are three levels in JIRA (from large to small): categories, projects, and components. Categories provide a view of related projects. Projects support versions, roadmaps, changelogs, etc. Components are subproject units to which specific issues can be assigned. If you haven't already, please visit a JIRA site and familiarize yourself with this layout (http://issues.apache.org/jira). There are currently two main proposals for how to organize our projects in JIRA: == The Aggregated Approach == Category: Avalon Avalon Excalibur Cornerstone Logkit Merlin Phoenix Fortress == The Component Approach == Category: Avalon avalon-extension-spi avalon-extension-impl avalon-framework-api avalon-framework-impl avalon-meta-api avalon-meta-impl avalon-meta-spi avalon-meta-tools avalon-meta-plugin avalon-composition-api avalon-composition-impl avalon-composition-spi avalon-activation-api avalon-activation-impl avalon-activation-spi avalon-util-exception avalon-util-criteria avalon-util-defaults avalon-util-env avalon-plugin avalon-repository-api avalon-repository-impl avalon-repository-main avalon-repository-spi avalon-repository-util Fortress Phoenix LogKit Category: Merlin merlin-api merlin-cli merlin-impl merlin-plugin merlin-unit Category: Cornerstone cornerstone-connection-api cornerstone-connection-impl cornerstone-datasources-api cornerstone-datasources-impl cornerstone-scheduler-api cornerstone-scheduler-impl cornerstone-sockets-api cornerstone-sockets-impl cornerstone-store-api cornerstone-store-impl cornerstone-threads-api cornerstone-threads-impl Category: Excalibur excalibur-compatibility excalibur-component excalibur-configuration excalibur-datasource excalibur-event excalibur-i18n excalibur-instrument-manager excalibur-instrument excalibur-lifecycle excalibur-logger excalibur-monitor excalibur-naming excalibur-pool excalibur-sourceresolve excalibur-thread There are obviously several other solutions, but these two approaches give us somewhere to start. Aggregated Pros * Maps well to our 'high-level' product list * Most Excalibur/Cornerstone projects are released together as a group. The same is true of Merlin (see recent release vote). * Easy to administer * Easily allows old components to be retired and new ones added. Aggregated Cons * Glosses over sub-component differences * Difficulty of determining proper level of aggregation (should things like repository and meta be in a group with framework?) * Cannot properly track versions for components. There will be some discrepancy in artifact versions vs JIRA versions. Changelogs and Roadmaps will also reflect this. Component Pros * Maps well to our actual versioned products (or maven artifacts). * Individual change logs and roadmaps for each project * Encourages each component to have its own release cycle Component Cons * Difficult to administrate and view/browse (there's over 60!) * Greater likelihood of issues getting assigned incorrectly * Requires new projects be created in the future for all new components. Deprecated components will remain as a project in JIRA. = Closing Thoughts and a VERY biased opinion = The issue of how to organize is really all about 'view.' To put it in maven terms, one is a view of the GroupID level, the other is a view of the individual ArtifactID. ( On a tangent, I'd like to point out that we don't have groups and artifacts very well defined and this might be a good time to get that ironed out as well. ) It's also interesting to note that in the current Bugzilla setup we have one product (project), Avalon, and three components: Avalon, Excalibur, Framework. My very biased opinion: go with the aggregated view. Avalon is complicated already. The component view only seems to add to that complexity. Let's keep it simple. Moreover, and I think this is a VERY important point, if we made the 'component' list a year ago, it would have looked different. Very different in fact. While we can always request new projects be made, this approach seems like an administrative nightmare. We regularly have components being sent over to jakarta-commons and new ones popping in and out of the sandbox. The aggregated approach will be more dynamic and more easily grow with Avalon. For those who are concerned about Roadmaps and Changelogs and versions, I would like to point out that we're currently releasing products as groups anyways. See the current merlin release. Look at how we've released Excalibur and Cornerstone in the past. It won't be that hard to point out in the release notes which artifact versions correspond with which group release version. And anything would be an improvement over the current situation in which good Roadmaps and Changelogs and issue tracking is all but nonexistent. Finally, I feel it would be easier to start small and grow if necessary. Most of us are new to JIRA. It will be much easier to break out issues into new projects than aggregate later. I will fully support whatever approach the developer community decides on. I'm very excited to make this move and see Avalon improve as a result. -- jaaron <http://jadetower.org> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
