Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: error (athena.apache.org: local policy)
From: =?ISO-8859-1?Q?Herv=E9?= BOUTEMY <herve.boutemy@free.fr>
To: infrastructure@apache.org, dev@maven.apache.org
Subject: Re: JIRA projects for Maven
Date: Wed, 07 Jan 2015 08:20:16 +0100
Message-ID: <17327648.kgy7eOP4ym@herve-desktop>
User-Agent: KMail/4.13.3 (Linux/3.13.0-43-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <54AAB944.60508@apache.org>
References: 
 <CALhtWkeZUiX0_z9k54EOkSDQ36To8KyEg_Nr0NTOomJjCezEvA@mail.gmail.com>
 <CALhtWkfHdSXVPhoiysYKW_ZJZaTWw+Md1zrKOwSmiDfFE4pa1Q@mail.gmail.com>
 <54AAB944.60508@apache.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

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=20
Jira project

notices:
1. account dedup will have to work when executed multiple times, since =
a lot=20
of accounts are shared between Maven Jira projects
2. I still didn't understand: will the Jira issue identifiers change or=
 not?=20
Will Codehaus MPLUGIN-288 migrate to MPLUGIN-288 in ASF or is there a r=
isk=20
that it changes?

Regards,

Herv=E9

[1] http://jira.codehaus.org/browse/MPLUGIN

Le lundi 5 janvier 2015 16:18:12 Mark Thomas a =E9crit :
> 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.
>=20
> 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.
>=20
> In reality I expect the first time to be difficult as all the wrinkle=
s
> are ironed out and subsequent ones would be easier.
>=20
> Mark
>=20
> > On Mon, Jan 5, 2015 at 8:22 AM, Mark Thomas <markt@apache.org> wrot=
e:
> >> On 05/01/2015 13:18, Benson Margulies wrote:
> >>> Codehaus:
> >>>=20
> >>> JIRA v6.1.6
> >>>=20
> >>> Apache:
> >>>=20
> >>> JIRA v6.3.4
> >>>=20
> >>> Not so good.
> >>=20
> >> But manageable. It is a pain but the following sequence would work=
.
> >>=20
> >> 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.
> >>=20
> >> Mark
> >>=20
> >>> On Mon, Jan 5, 2015 at 7:46 AM, Mark Thomas <markt@apache.org> wr=
ote:
> >>>> 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 ap=
proach
> >>>>> to migrating a project?
> >>>>=20
> >>>> For the migration to work (using Jira import/export):
> >>>> - Source and destination Jira versions need to be exactly the sa=
me.
> >>>> - Some plug-ins also must be aligned. Agile is one such plug-in.=

> >>>>=20
> >>>> 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 t=
o deal
> >>>> with this is a global search and replace in the exported xml. Ma=
tch
> >>>> users by e-mail address and de-conflict by adding "-maven" to
> >>>> all/conflicting imported names.
> >>>>=20
> >>>> 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 sensitiv=
e so
> >>>> there will be restrictions in place to ensure it is accessed sec=
urely).
> >>>>=20
> >>>> 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 pro=
ject.
> >>>> I'm happy to drive that.
> >>>>=20
> >>>> Note that the more cruft you can remove from your Jira instance(=
s)
> >>>> before you export, the better.
> >>>>=20
> >>>> Mark
> >>>>=20
> >>>>> On Mon, Dec 29, 2014 at 2:10 AM, Herv=E9 BOUTEMY <herve.boutemy=
@free.fr>=20
wrote:
> >>>>>> Le dimanche 28 d=E9cembre 2014 21:18:18 David Nalley a =E9crit=
 :
> >>>>>>> On Sat, Dec 27, 2014 at 11:37 AM, Benson Margulies
> >>>>>>>=20
> >>>>>>> <bimargulies@gmail.com> wrote:
> >>>>>>>> Dear Infra,
> >>>>>>>>=20
> >>>>>>>> For historical reasons, the Maven project has a host of JIRA=

> >>>>>>>> projects
> >>>>>>>> at codehaus. This is not an ideal situation for many reasons=
.
> >>>>>>>>=20
> >>>>>>>> In the past, discussions on moving onto ASF infrastructure h=
ave
> >>>>>>>> founded on the sheer number: dozens. Infrastructure didn't f=
eel
> >>>>>>>> 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.
> >>>>>>>=20
> >>>>>>> Can you tell me why it would be difficult? E.g. I am envision=
ing a
> >>>>>>> single maven project, an each plugin has a component instead =
of a
> >>>>>>> separate project.
> >>>>>>=20
> >>>>>> we use such a schema for parent POMS at ASF with success: 4
> >>>>>> components [1]
> >>>>>>=20
> >>>>>> we do the same for "shared components" at Codehaus, and it's a=

> >>>>>> nightmare: 30 components [2], with a dedicated roadmap/changel=
og for
> >>>>>> each
> >>>>>>=20
> >>>>>> for plugins, we have 1 Jira project for each of our ~45 plugin=
s (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)
> >>>>>>=20
> >>>>>> Clearly, changing plugins Jira model to shared components Jira=
 model
> >>>>>> would not fit: even more plugins than shared components, and w=
e
> >>>>>> would loose Jira components as plugin-internal structure
> >>>>>>=20
> >>>>>> The question for the PMC would more be: what if we could split=
 shared
> >>>>>> components into smaller Jira projects?
> >>>>>>=20
> >>>>>>>> It seems to me that much has changed since the last time tha=
t this
> >>>>>>>> subject was explored, so I felt that it was worth re-opening=
 the
> >>>>>>>> discussion. Could the existing main JIRA support a large inf=
lux of
> >>>>>>>> low-activity projects? Or would infra consider a separate in=
stance?
> >>>>>>>=20
> >>>>>>> The number of projects is not a huge issue. Jira can support =
many
> >>>>>>> magnitudes more 'projects' than we currently have.
> >>>>>>>=20
> >>>>>>> Migrating 61 low-activity projects seems like a lot of work;
> >>>>>>> historically, that's involved dumping to XML, potentially dep=
loying
> >>>>>>> to
> >>>>>>> a matching version of the source, and then upgrading the vers=
ion to
> >>>>>>> match the destination version of Jira, then exporting again a=
nd
> >>>>>>> deploying to the destination version. Generally (depending on=
 the
> >>>>>>> way
> >>>>>>> the restore happens) the ticket numbers may not stay the same=
.
> >>>>>>=20
> >>>>>> the ticket IDs or the ticket count?
> >>>>>> changing ticket IDs would be a pain, since it is used in scm c=
omments
> >>>>>> to track details
> >>>>>>=20
> >>>>>>> Historically, we've had a lot of frustration on this front wh=
en
> >>>>>>> we've
> >>>>>>> attempted migrations. Though generally they tend to be larger=

> >>>>>>> migrations.
> >>>>>>>=20
> >>>>>>> That said, how much of this work is Maven willing to bear?
> >>>>>>=20
> >>>>>> as much as possible if we can do it Jira project per Jira proj=
ect:
> >>>>>> 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.
> >>>>>>=20
> >>>>>> Regards,
> >>>>>>=20
> >>>>>> Herv=E9
> >>>>>>=20
> >>>>>>> --David
> >>>>>>=20
> >>>>>> [1]
> >>>>>> https://issues.apache.org/jira/browse/MPOM/?selectedTab=3Dcom.=
atlassian
> >>>>>> .jira.jira-projects-plugin:components-panel
> >>>>>>=20
> >>>>>> [2]
> >>>>>> http://jira.codehaus.org/browse/MSHARED#selectedTab=3Dcom.atla=
ssian.jir
> >>>>>> a.plugin.system.project%3Acomponents-panel
> >>>>>>=20
> >>>>>> [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