Difference between revisions of "Commit access"
(Created page with "== What is commit access? == Having commit access means you have the ability to push code directly to the main Pioneer repository. Its expected that anyone with commit acces...") |
|||
| Line 2: | Line 2: | ||
Having commit access means you have the ability to push code directly to the main Pioneer repository. | Having commit access means you have the ability to push code directly to the main Pioneer repository. | ||
| − | |||
| − | |||
== How do I get commit access? == | == How do I get commit access? == | ||
| Line 21: | Line 19: | ||
=== Code review === | === Code review === | ||
| − | Read the page about the [[Code_review|code review process]]. | + | Read the page about the [[Code_review|code review process]]. You're expected to be reviewing your own code according to the guildlines set out there, and you're encouraged to find another person to review your code if its particularly large or complex. Read that page for more info about that. |
| + | |||
| + | There is no obligation for commiters to review other people's work, but it would be very helpful if you could. If everyone is involved, then the total workload on any individual remains small, giving everyone time to work on their code. | ||
=== Update the changelog === | === Update the changelog === | ||
| − | Changelog.txt is where we track the history of the project. Each time you make a change, add a brief description of it to the Changelog. Include the Github issue or pull request number if it has one. The description should be something that is understandable by players. Choose an appropriate category, start a new month header at the start of the month, and preserve the existing formatting. Have a look through the history to get a feel for how it works. | + | [https://github.com/pioneerspacesim/pioneer/blob/master/Changelog.txt Changelog.txt] is where we track the history of the project. Each time you make a change, add a brief description of it to the Changelog. Include the Github issue or pull request number if it has one. The description should be something that is understandable by players. Choose an appropriate category, start a new month header at the start of the month, and preserve the existing formatting. Have a look through the history to get a feel for how it works. |
=== Don't break the build === | === Don't break the build === | ||
| − | Pioneer is regularly built by an autobuild script, sometimes as often as once per day. This is done using the Makefile/autotools system (all platforms). You must take care to ensure that everything that lands on the master branch builds correctly with the autotools/GCC build. This could be a problem for Windows-based developers using | + | Pioneer is regularly built by an autobuild script, sometimes as often as once per day. This is done using the Makefile/autotools system (all platforms). You must take care to ensure that everything that lands on the master branch builds correctly with the autotools/GCC build. This could be a problem for Windows-based developers using MSVC; please do the best you can and ask for help if you need it. |
Revision as of 12:22, 15 January 2014
Contents
What is commit access?
Having commit access means you have the ability to push code directly to the main Pioneer repository.
How do I get commit access?
Usually, just by asking. If you're known to the other committers to be someone who can be trusted to be a good steward of the project (usually shown by the quality of previous contributions) then you'll be given access to push to the repository. This is deliberately a subjective measure, but rest assured, the bar is set pretty low. Its mostly just a check to make sure you aren't going to do something stupid.
In some circumstances you might be offered commit access. The same bar is set there. It usually happens when the other committers finds themselves thinking "this person would be a good committer".
What do I need to know when pushing?
There's a few things that are special to the way we work that you need to know about.
Code style
We have a code style guide. Learn it, love it. There's almost certainly something in there you'll hate, because we all have different opions on code style. Don't argue, just use it - its what we've got!
Code review
Read the page about the code review process. You're expected to be reviewing your own code according to the guildlines set out there, and you're encouraged to find another person to review your code if its particularly large or complex. Read that page for more info about that.
There is no obligation for commiters to review other people's work, but it would be very helpful if you could. If everyone is involved, then the total workload on any individual remains small, giving everyone time to work on their code.
Update the changelog
Changelog.txt is where we track the history of the project. Each time you make a change, add a brief description of it to the Changelog. Include the Github issue or pull request number if it has one. The description should be something that is understandable by players. Choose an appropriate category, start a new month header at the start of the month, and preserve the existing formatting. Have a look through the history to get a feel for how it works.
Don't break the build
Pioneer is regularly built by an autobuild script, sometimes as often as once per day. This is done using the Makefile/autotools system (all platforms). You must take care to ensure that everything that lands on the master branch builds correctly with the autotools/GCC build. This could be a problem for Windows-based developers using MSVC; please do the best you can and ask for help if you need it.
