With each passing day, technically capable consumers of computing technology increasingly lose their rights with computer hardware. The successful deployment of UEFI in the market, with Microsoft controlling which operating systems receive a key that permits it to be booted, poses a potential threat to OS development freedom. While some look to prominent Linux suppliers as an escape from the Intel/Microsoft monopoly, I have taken a different route -- I decided to build my own computer completely from scratch. My computer architecture is fully open; anyone can review the source, learn from, and hack it to suit their needs.
The Kestrel project is all about freedom of computing and self-education using all-homebrew design, right down to having openly documented hardware and software at all levels, from schematics and register-transfer logic all the way up to OS API and user tutorials. Its design is informed from a variety of sources based on my experience:
The "master" branch must always be a valid build, and as such, always represents the current release. Changes queued for the next release will be placed on a branch named "working". Feature branches, therefore, must be derived off of the working branch.
To create a feature branch:
git checkout working git pull git checkout -b featureBranch git checkout -b featureBranch-wip
Perform all your edits in the WIP branch. Commit as often as you feel comfortable. You may even open pull requests on the WIP branch; however, no PR opened from a WIP branch will ever be merged.
To merge code, squash all your commits into the non-wip branch, like so:
git checkout featureBranch git merge --squash featureBranch-wip git commit -a git push -u origin featureBranch
You may now open a pull request from your featureBranch into the working branch. Pull requests into master will be categorically closed.
The "git commit -a" step will open a text editor allowing you to enter a commit log. This log should answer the following questions, where appropriate:
Remember that monster-sized pull requests are a bear to code review, so having helpful commit logs are an absolute must to review changes as quickly and easily as possible.
Finally, if you break the build or environment, you're ultimately responsible for fixing it.
The age of 80-column punch cards are over; I think most people have monitors capable of showing at least 132 columns of text these days. Use them. However, remember that the longer the line, especially those exceeding 132 characters, the more likely splitting a line might make some sense. Use best judgement here; I regularly break long lines, but I also regularly exceed the 80-character limit too.
Pull requests that lack adequate tests will be called out, or even rejected. Make sure your code is tested. Where applicable, try to write your tests first, following test-driven development practices.