Moving Ext I18N module under OpenMRS

Tags: #<Tag:0x00007f88d54d8bd0> #<Tag:0x00007f88d54d87c0> #<Tag:0x00007f88d54d84a0>

(Dimitri R) #1

Hi all,

I would like to create a new repo under OpenMRS for Ext I18N:

Just wondering about best practices and implications:

  • I guess I should not fork but instead push the current history directly to the new repo?
  • Should I squash the pre-OpenMRS history or just keep it as it is?
  • What about JIRA, where would issues be tracked about it?

Any comments or suggestions are welcome!

Problem Setting up Drug data using CSV import
(Dimitri R) #2

Well I guess I will just go ahead then… :slight_smile: And I will also create a Bamboo plan for that one.

(Burke Mamlin) #3

Hey @mksd. Sometime’s the community’s silence can be deafening. :wink:

Yes. Migrate, do not fork.

Keep it as is.

We’d create a JIRA project for it.

(Dimitri R) #4

Thanks @burke. There’s actually a ‘Transfer ownership’ button, I just did that and now Ext I18N has become an OpenMRS project! I gave access to all /dev/3 in order for me to not loose access, I hope that’s ok?

Regarding JIRA… sure, but I personally think it’s a bit overkill. I would rather see Ext I18N as a component of a project dedicated to gather such components in one place. The day a component deserves its own project, one can always select its issues and move them to the project created for the occasion.

Cc @mksrom

(Dimitri R) #5

Actually that was a bad idea, I can’t push to it anymore :frowning: Could someone grant me the appropriate access on that new repo?

Internally at MKS we use a ‘dev’ branch as the main “develop” branch, and this remained through transferring the repo to OpenMRS. It is while attempting to rename the default branch to ‘master’ that I realised that I couldn’t write to it anymore…

(Mike Seaton) #6

I just went in and made you an admin.

(Daniel Kayiwa) #7

I also noticed that /dev/3 had Read instead of Write access.

(Burke Mamlin) #8

FYI – for the majority of repos, /dev/1 & /dev/2 get read access, /dev/3 & /dev/4 have write access, and /dev/5 has admin access. Folks who need additional access (e.g., a /dev/2 needing write access or a /dev/3 needing admin access), we add them as collaborators in the specific repo with the additional access.

(Dimitri R) #9

Everything is set up, including Bamboo. The first SNAPSHOT is in the box on Nexus. I will do a commit for the TravisCI build and everything should be in order.

Thanks all!

(Dimitri R) #10

Ok two more questions:

(Q1.) Who’s responsible to add the TravisCI service to the GitHub repo?

(Q2.) Should a webhook be added for triggering Bamboo buids, or how does that work?

(Daniel Kayiwa) #11

Q1: I think you may need to write to help desk. Q2: As you can see here, Bamboo is already triggered for every commit:

(Dimitri R) #12

Great! Somehow I didn’t see that #2 build… Ok helpdesk case created!

(Burke Mamlin) #13

8 posts were split to a new topic: Configuring CI for exti18n module

(Dimitri R) #14

Ok! I could finally release Ext I18N 1.0.0. A few tips for others and for reference…

The variable maven.release.version is the release version to come (obviously). Whereas the variable maven.development.version is the next desired development version. Working example:

In the main POM all this is necessary:

  • The distribution management section, example:
  <name>OpenMRS Modules</name>
  <name>OpenMRS Snapshots</name>
  • The Maven release plugin, example: