Code documentation

Development Tools

Code Structure

Techniques and Standards

Help and Web Site

How To

Functional Info

Background Info

JMRI Help:
Contents/ Index
Glossary/ FAQ

Donate to JMRI Donate to JMRI.org

JMRI Code: GitHub Administration

Background

JMRI uses GitHub to host our main code repository, releases and downloads and issues lists. It also hosts several related repositories.

The rest of this page records how we configure and use GitHub, along with associated procedures.

Related info on other pages:

Merging a PR

JMRI's Github is configured with the following automations and requirements for merging a Pull Request:

If you want a bit more time before somebody merges a PR, either start a review saying that or set "WIP" in the title while explaining why in a comment.

When reviewing a pull request, the focus should be on function and not style. The following should be considered when reviewing a pull request:

If there are any concerns about any of the above, the reviewer should either ask a question about the pull request or request changes. Significant discussions should move to the jmri-developers list to make sure people are aware of them.

When restarting CI after a failure, please copy at least a few lines around the relevant part of the log to a comment. It can be very useful to attach the entire raw log if the failure is obscure, novel or otherwise needs investigation.

When merging a PR, please do the following:

How we use GitHub teams

GitHub provides support for teams to control access to various GitHub features. We use three different ones:

Developers
Have the "Triage" permissions, which allows editing of PRs, including adding/changing labels, releases, and other properties.
Reviewers
In addition to "Triage" permissions also has "Write" permissions which allows reviewing of PRs, but are blocked from merging to the "master" branch (subject to other rules and restrictions)
Maintainers
In addition to "Triage" permissions also has "Write" permissions which allows merging PRs (subject to other rules and restrictions)

Terms for adding people to developer team - still being developed

Branches

What do we keep as main repository branches (as opposed to in user repositories, which is not our problem)? When do we clean them out?