Repository work flow structure

Overview

Our official repository is kept on sourceforge via git. We recently migrated from cvs to git, which is described HERE. Our sourceforge repository also has three official mirrors, which are described HERE. The proper way for individual developers to set up their personal git repository is described HERE. To avoid breaking the main sourceforge git repository, we are using the following work flow and development structure:

Developer roles and work flow

Integration Developers

• These are the only developers with commit access to the sourceforge repository.
• They have demonstrated common sense and proficiency in git and OpenEMR development.
• They are responsible for committing their own code.
• They are willing to commit the code of the "Privileged Developers" (when requested).
• Standardized methods to commit to the sourceforge repository have been documented in the 'Advanced Usage' section of the page HERE . Rather than pull in the entire remote branch of somebody else's code, recommend pulling in each commit via the 'cherry-pick' command (this is specifically documented HERE).

Privileged Developers

• These are developers that have demonstrated common sense and proficiency in OpenEMR development.
• They do not have commit access to the sourceforge repository.
• Their code will be directly committed to the sourceforge repository upon request to an "Integration Developer" in the Developer forum. (will be committed within 24 hours). To clarify, this is for code that is ready to be committed; ie. do not request commits of code that might need further review.

• To take advantage of this "fast-track" commit, you need to submit code via a public git branch. (instructions on how to do this can be found here). If this is done correctly, then it only takes an "Integration Developer" several minutes to commit your code to the sourceforge repository.

Standard Developers

• Standard developers whom have or are in process of submitting code.
• They do not have commit access to the sourceforge repository.
• Their code needs to be reviewed before committing to the sourceforge repository.

• Best way to do this is to submit code via a public git branch. (instructions on how to do this can be found here). If this is done correctly, then it only takes an "Integration Developers" several minutes to commit your code to the sourceforge repository if deemed acceptable by the community review.

Developers

(Requires a sourceforge account - Only sourceforge account name, company association, and link to their public repository are shown.)

(Ideally, each developer should have their own sourceforge account along with a public repository, which is labeled 'personal repository'.)

(Names are alphabetically ordered)

Integration Developers

bradymiller (personal repository)

stephen-smith (personal repository)

sunsetsystems (Rod at Sunset Systems) (personal repository)

tmccormi (Tony at Medical Information Integration) (personal repository)

Privileged Developers

acmoore

andres_paglayan

cfapress

coleedo (Connie at Phyaura) (personal repository)

drbowen (Sam at Medical Information Integration)

larrylart

markleeds

mmfsystems (Vineet at MMF Systems)

rachoac (Aron at Medical Information Integration)

tekknogenius

visolve-selvi (Selvi at Visolve) (personal repository)

whimmel (Bill at Phyaura) (personal repository)

zhhealthcare (Paul, Jacob, Sam, and Eldho at Z&H Healthcare Solutions) (personal repository)

Standard Developers

aethelwulffe

apmuthu

arnabnaha (personal repository)

bo2999

clucena (Chris at EHRLive) (personal repository)

dlee5400

hrivera787 (personal repository)

ideaman911 (Joe at Idea Man div Holzer Enterprises)

jason0

jjwjj

jwallace00 (Jeremy at Medical Information Integration) (personal repository)

kjs3250

meditcare

penguin8r

yehster (personal repository)

ytiddo

(All other developers not mentioned also fall into this category)