Created Contributing (mediawiki)
parent
c6e2d57be1
commit
f0c1f39c33
1 changed files with 34 additions and 0 deletions
34
Contributing.mediawiki
Normal file
34
Contributing.mediawiki
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
There are many ways that RepRap enthusiasts, owners and builders of 3D printers, and sprightly startups can contribute to Marlin.
|
||||
|
||||
* '''Report Issues'''<br/>The [https://github.com/MarlinFirmware/Marlin/issues Marlin Issue Queue] is the place to get help and make suggestions. The only way that bugs get fixed in Marlin is if we know about them, so don't hesitate to let us know if you have any problems.
|
||||
** '''''Please follow our [[Reporting Bugs|Bug Reporting Guidelines]] when submitting bugs.'''''
|
||||
* '''Become a Marlin Tester'''<br/>To get the code tested as widely as possible we rely on volunteers with a wide variety of hardware configurations to test Marlin and help us to certify it as bug-free. If you'd like to help us test the latest cutting-edge code, please [https://github.com/MarlinFirmware/Marlin/issues/1209 tell us about your machine!]
|
||||
* '''Contribute Code'''<br/>If you have reasonable skills with C++, Python, perl, or object-oriented Javascript then you have what it takes to write code for Marlin. The main codebase is written entirely in Embedded C++. Slicers and hosts that work with Marlin are typically coded in Python or perl.
|
||||
* '''Write Documentation'''<br/>This wiki is now the central location for all Marlin documentation, and we are just getting started in writing it. If every Marlin user volunteers just a few minutes each day to help with the wiki, the documentation will soon be complete.
|
||||
|
||||
|
||||
=== Developer Notes ===
|
||||
|
||||
==== Becoming a Developer ====
|
||||
|
||||
To contribute to Marlin, you will need to have a free Github account and make a fork of Marlin under your account. Before making any changes, you should make a new branch based on the Development branch. If you plan to maintain a Marlin fork for a while, you will need to periodically refresh your Development branch to keep it in sync, or you can set an upstream remote you use MarlinFirmware/Development as the basis for all your merging, rebasing, and branch creation.
|
||||
|
||||
==== MarlinFirmware Branches ====
|
||||
Marlin now has 3 branches:
|
||||
* [https://github.com/MarlinFirmware/Marlin/tree/Development Development]: New features and code changes are sorted out here. This branch may have untested code in it, so please report bugs.
|
||||
* [https://github.com/MarlinFirmware/Marlin/tree/Integration Integration]: Features and changes deemed to be bug-free are integrated into this branch as candidates for later release.
|
||||
* [https://github.com/MarlinFirmware/Marlin/tree/Release Release]: After a code-freeze period when only bugs are fixed and no new features are added, a release candidate is tagged, and after a public test period with bugs addressed, a full release is tagged.
|
||||
|
||||
==== Verify/Compile First ====
|
||||
Before you submit any pull request, we ask that you PLEASE test your code, even if the change seems innocuous. We have automated tools to catch compile and link errors, but we would rather not have any commits that break compilation. When creating the pull request, please include the hardware you used for testing and a short synopsis of your testing procedure. Untested pull requests are less likely to be merged, as even slight changes create the risk of breaking the main branch.
|
||||
|
||||
==== Make a Pull Request ====
|
||||
If you've implemented a fix or feature in your own Marlin, don't just tell us about it! Test the code, submit a Pull Request, and work with us to get it properly integrated. You should always make a new branch based off the MarlinFirmware/Development upstream before applying changes. Pull requests in a branch named Development may be rejected.
|
||||
|
||||
==== Merging Commits ====
|
||||
If a pull request has many commits, you should make a new branch and use <code>git rebase -i</code> to combine all your commits into a smaller number, then submit a brand new pull request.
|
||||
|
||||
Here's a good trick to combine all the changes in your feature branch into a single commit without worrying about merge:
|
||||
|
||||
git checkout Development -b my_feature_clean
|
||||
git diff Development origin/my_feature_messy | git apply
|
||||
Loading…
Add table
Add a link
Reference in a new issue