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]
