maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: JIRA projects for Maven
Date Mon, 05 Jan 2015 13:18:08 GMT
Codehaus:

JIRA v6.1.6

Apache:

JIRA v6.3.4

Not so good.

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.jira.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