maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: JIRA projects for Maven
Date Wed, 07 Jan 2015 07:20:16 GMT
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 <markt@apache.org> 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 <markt@apache.org> 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 <herve.boutemy@free.fr>

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
> >>>>>>> 
> >>>>>>> <bimargulies@gmail.com> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message