Our GitHub repository is wonderful in many ways. To keep it wonderful, committers should follow a few simple guidelines.
Code in the openmrs-core ''master'' branch should always build but does not always have to run smoothly.
The code in the ''other branches'' in openmrs-core does not have to compile or run. It is all up to the branch creator/maintainer(s).
The code in openmrs-module-* repos does not have to compile or run. It is all up to the module source creator/maintainer(s).
The code in openmrs-contrib-* repos does not have to compile or run. It is all up to the specific contributor(s).
/dev/4 and /dev/5 developers can push fixes to openmrs-core or merge pull requests. The associated ticket should be marked as "Committed Code" so as to be in the "Code Review (post commit)" state.
All others cannot push to openmrs-core, but are encouraged to open pull requests instead.
Any major feature additions or code overhauls should be submitted to a branch or fork. Forking and branching is quick and easy: don't be afraid of it.
All new features should be developed in a fork or branch. This allows the developer to adhere to the policy of committing early and often much more easily than if the feature were developed directly on openmrs-core.
All developers are expected to watch source code that is committed (e.g., via the "watch" feature shown on the openmrs-core repo) and give the one who is committing feedback. The committing developer must be open to suggestions and constructive criticism.
When a feature has been fully developed and tested, it can be merged back into openmrs-core by a /dev/4 or /dev/5. Merging "permission" should be acquired from the other full-access developers prior to the merge (see Git Branching and Merging Techniques).
To request that your module repository be migrated to the OpenMRS organization in GitHub, please ensure that it meets the above criteria, then:
Post to OpenMRS Talk > Repo Management and include:
/cc @username1, @username2, ..." to the end of your post.
Each repository should contain a README.md in the root folder. The
.md extension for a README refers to markdown syntax.
Your README should contain at least two sections: description and installation. For example:
== Description == This should be the description of your module. Write your description in a way that will help someone who knows nothing about your module or your projects to understand the purpose of your module and what feature(s) it provides. If there are additional resources/documentation that describe your moule, then direct the reader to those resources in your description.
This section outlines the different scenarios and sections in which commits occur. Find the one that best matches yours and follow that.
Commits to openmrs-core
TRUNK-123: Fixing feature XXX
where "Fixing feature XXX" is a descriptive sentence about the error/function being corrected and TRUNK-123 is the jira ticket id.
TRUNK-123: Fixing bug that caused X if Y was done
Adding functionality X
MODULE-123: Adding functionality X
Merging dictionary-import to which provides functionality X, Y, and Z
TRUNK-123: Adding feature XXX or fixing bug YYY
Where 123 is the ticket the patch came from.
Be sure to include the module's id and the username of the intended user
Creating module formentry for bwolfe