What will happen to cross references if we move ? (Relations to other issues in differnt projects, relations to plexus issues)
Kristian 2015-01-07 8:20 GMT+01:00 Hervé BOUTEMY <[email protected]>: > ok > who can prepare a little VM with Jira 6.3.4? Can infra? > > and how to get Codehaus content? Any maven dev with knowledge and karma? > > > I'm interested to try the process on MPLUGIN [1] > then be ready for later any Mave developer to do the same for each and every > Jira project > > notices: > 1. account dedup will have to work when executed multiple times, since a lot > of accounts are shared between Maven Jira projects > 2. I still didn't understand: will the Jira issue identifiers change or not? > Will Codehaus MPLUGIN-288 migrate to MPLUGIN-288 in ASF or is there a risk > that it changes? > > Regards, > > Hervé > > [1] http://jira.codehaus.org/browse/MPLUGIN > > Le lundi 5 janvier 2015 16:18:12 Mark Thomas a écrit : >> On 05/01/2015 13:25, Benson Margulies wrote: >> > Presumably, you wouldn't want to repeat that exercise over and over >> > for each of 62 projects. >> >> If you used a VM and took a snapshot of the initial install (so you >> could go back for each project) then upgraded via the 'rapid upgrade' >> the process shouldn't be too painful. >> >> In reality I expect the first time to be difficult as all the wrinkles >> are ironed out and subsequent ones would be easier. >> >> Mark >> >> > On Mon, Jan 5, 2015 at 8:22 AM, Mark Thomas <[email protected]> wrote: >> >> On 05/01/2015 13:18, Benson Margulies wrote: >> >>> Codehaus: >> >>> >> >>> JIRA v6.1.6 >> >>> >> >>> Apache: >> >>> >> >>> JIRA v6.3.4 >> >>> >> >>> Not so good. >> >> >> >> But manageable. It is a pain but the following sequence would work. >> >> >> >> 1. Install a temp Jira instance using same version as Codehaus. >> >> 2. Export data from Codehaus >> >> 3. Import this data to the temp instance. >> >> 4. Upgrade the temp instance to the version the ASF is using. >> >> 5. Export the data from the temp instance. >> >> 6. Import the data to the ASF instance. >> >> >> >> Mark >> >> >> >>> On Mon, Jan 5, 2015 at 7:46 AM, Mark Thomas <[email protected]> wrote: >> >>>> On 05/01/2015 12:22, Benson Margulies wrote: >> >>>>> So, where are we? David N, can we go ahead and start asking to create >> >>>>> projects as we migrate? Maven gang, do we have a mechanical approach >> >>>>> to migrating a project? >> >>>> >> >>>> For the migration to work (using Jira import/export): >> >>>> - Source and destination Jira versions need to be exactly the same. >> >>>> - Some plug-ins also must be aligned. Agile is one such plug-in. >> >>>> >> >>>> On top of that there is the issue of matching user names in the source >> >>>> and destination and dealing with any clashes. The simplest way to deal >> >>>> with this is a global search and replace in the exported xml. Match >> >>>> users by e-mail address and de-conflict by adding "-maven" to >> >>>> all/conflicting imported names. >> >>>> >> >>>> We can provide a list of user names and e-mail addresses for you to do >> >>>> this yourselves (obviously the contents of that file is sensitive so >> >>>> there will be restrictions in place to ensure it is accessed securely). >> >>>> >> >>>> I'd suggest starting with a small project and seeing how things go. >> >>>> Someone from infra will need to do the final import for each project. >> >>>> I'm happy to drive that. >> >>>> >> >>>> Note that the more cruft you can remove from your Jira instance(s) >> >>>> before you export, the better. >> >>>> >> >>>> Mark >> >>>> >> >>>>> On Mon, Dec 29, 2014 at 2:10 AM, Hervé BOUTEMY <[email protected]> > wrote: >> >>>>>> 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.jir >> >>>>>> a.plugin.system.project%3Acomponents-panel >> >>>>>> >> >>>>>> [3] http://maven.apache.org/plugins/ > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
