Le dimanche 28 décembre 2014 21:18:18 David Nalley a écrit : > On Sat, Dec 27, 2014 at 11:37 AM, Benson Margulies > > <[email protected]> wrote: > > Dear Infra, > > > > For historical reasons, the Maven project has a host of JIRA projects > > at codehaus. This is not an ideal situation for many reasons. > > > > In the past, discussions on moving onto ASF infrastructure have > > founded on the sheer number: dozens. Infrastructure didn't feel that > > they could support that many project, and the Maven project felt that > > it would be very difficult to combine all of the many per-maven-plugin > > JIRA projects into a single project with many components. > > Can you tell me why it would be difficult? E.g. I am envisioning a > single maven project, an each plugin has a component instead of a > separate project. we use such a schema for parent POMS at ASF with success: 4 components [1]
we do the same for "shared components" at Codehaus, and it's a nightmare: 30 components [2], with a dedicated roadmap/changelog for each for plugins, we have 1 Jira project for each of our ~45 plugins (see "issue tracking" column on [3]), with components for internal details (no roadmap or changelog per component here, see Jira project for plugin or site or dependency) Clearly, changing plugins Jira model to shared components Jira model would not fit: even more plugins than shared components, and we would loose Jira components as plugin-internal structure The question for the PMC would more be: what if we could split shared components into smaller Jira projects? > > > It seems to me that much has changed since the last time that this > > subject was explored, so I felt that it was worth re-opening the > > discussion. Could the existing main JIRA support a large influx of > > low-activity projects? Or would infra consider a separate instance? > > The number of projects is not a huge issue. Jira can support many > magnitudes more 'projects' than we currently have. > > Migrating 61 low-activity projects seems like a lot of work; > historically, that's involved dumping to XML, potentially deploying to > a matching version of the source, and then upgrading the version to > match the destination version of Jira, then exporting again and > deploying to the destination version. Generally (depending on the way > the restore happens) the ticket numbers may not stay the same. the ticket IDs or the ticket count? changing ticket IDs would be a pain, since it is used in scm comments to track details > Historically, we've had a lot of frustration on this front when we've > attempted migrations. Though generally they tend to be larger > migrations. > > That said, how much of this work is Maven willing to bear? as much as possible if we can do it Jira project per Jira project: each migration could be done when a release is done We "just" need to learn how to do both on Codehaus and on ASF sides: have a few key people on the PMC who will help the others do the job Jira project per Jira project over time. I'm sure we can get a few volunteers, wanting to help and learn some Jira admin. Regards, Hervé > > --David [1] https://issues.apache.org/jira/browse/MPOM/?selectedTab=com.atlassian.jira.jira-projects-plugin:components-panel [2] http://jira.codehaus.org/browse/MSHARED#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel [3] http://maven.apache.org/plugins/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
