-
Notifications
You must be signed in to change notification settings - Fork 30
devpolicy
The main/official repository in the epics-modules github group is used for releases. Development is done outside of the official repositories (TODO: should this be just "not on the master branch?").
It is suggested to use the github fork process to create a personal repository to hold work in progress. Either as a prelude to creating a pull request, or to work with others as collaborators.
A developer may allow other github users to push changes to a personal repository by adding them as collaborators for that repository.
In the main/official repository the focus of active development is the branch called "master".
Release are tagged with a version number seperated by dots ("2.X.Y"). To avoid confusion all mrfioc2 versions will by in the two series (ie. there will never be a mrfioc2 version 3).
Minor changes by developers with permission may be pushed directly to the main repositories. Significant or contentious changes (ie. API breaks) should be posted for review prior to being included in the main repositories. Review through github pull requests in the preferred mechanism.
Pull request messages should clearly state any intentionally incompatible changes being made.
See the project wide list of open pull requests.
The threshold to trigger "formal" review is at the discretion of developers. Consideration should be given to the effects of the change. Changes which could be disruptive (ie. API breaks), or which carry a higher risk of bugs, are good candidates for review. If in doubt, ask.
TODO: Is this too vague? Are there specific cases which either should or shouldn't trigger a review?
TODO: I'd like to come up with a scheme for indicating who's comments are being waited on.
TODO: What is the end condition? Is it enough to say that one person for each site has to approve?
See the project list of open issues.