|CCL HomeSoftware Community Operations||
Sofware Development Values
Collaboration We work closely with our user community to identify problems and solutions of mutual benefit. Our work must have value to both the end users and to the research interests of the CCL.
Responsiveness When our software is known to have a defect that affects our users, we drop everything else to fix it. When a collaborator has a problem or an idea, we jump at the opportunity to learn from their perspective.
Minimality We strive to select the simplest effective solution to the problem at hand. It is much better to solve a small problem comprehensively than a large problem incompletely.
Portability We rely on widely deployed languages and systems, so that the software is usable on the widest variety of computing platforms with modest effort. We avoid depending on new technologies that are not essential to the task at hand.
Minimum Privilege Most of our users work in computing facilities where they do not have special privileges. Modying the operating system, the filesystem, the firewall, and other such facilities is simply impossible at scale. We seek to provide tools that can be built, deployed, and used with the least privilege possible.
Interoperability We gladly interoperate with the other systems and software important our user community.
We use git and github to manage our source code. The authoritative source code repository is known as main-line and is stored here:http://github.org/cooperative-computing-tools/cctools
We recommend that all developers create an account on github and then fork the cctools into their own private repository, which would be located here:http://github.org/YOURNAME/cctools
Senior members of the group (committers) will have commit rights to main-line. For junior members of the group and external contributors, the expected work-flow is:
When new members or external contributors want to incorporate a change into main-line, either from the local master or some other local branch, they will submit a code review request. Ben is the main person responsible for code reviews, but any of the senior members may resolve them. With a github account, the code review request is simply a pull request. Without a github account, a patch (man git-format-patch) should be sent to Ben.
We encourage the creation of branches, leaving the local master branch always as a mirror of main-line.
Guidance for the Developer
When submitting code for review, please consider the following:
Guidance for the Code Reviewer
Code reviews should be done with an eye towards high level issues of structure, functionality, and usability. Proposed changes to an existing, widely used tool require a higher level of scrutiny than newly created features. Avoid nitpicking on non-functional issues. The code reviewer should ask the following questions:
Guidance for the Release Manager
About four weeks before a planned release, a branch will be created from main-line, with the name of the release. New features will not be added to this 'release candidate' from this point on. The release wrangler will manually incorporate bug fixes added to main-line to the release candidate from this point on to the date of the release. The release wrangler will have two weeks to test the release candidate. This testing should include at least:
After this testing, the release candidate will be deployed internally in Notre Dame, in which it will be tested at least two weeks before release. The release wrangler will incorporate any bug fixes for the issues appearing in this time period.