DNE Contributing

DO NOT EDIT -- TRANSFERRED TO NEW WIKI

There are many ways that RepRap enthusiasts, owners and builders of 3D printers, and sprightly startups can contribute to Marlin.

• Report Issues
  The 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 Bug Reporting Guidelines when submitting bugs.
• Become a Marlin Tester
  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 code, please tell us about your machine!
• Contribute Code
  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
  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.

Table of Contents Developer Notes Becoming a Developer Release Candidates Current Development Verify/Compile First Make a Pull Request Patching Bugs In Releases Contributing New Features Merging Commits

Developer Notes

Becoming a Developer

To get involved with the latest **cutting-edge development and testing on Version 1.2 and beyond**, make a fork of the Marlin Development tree and then go to the Marlin Development Wiki for guidance on the new file layout, obtaining the hardware support package, and integrating Marlin with Arduino >= 1.6.7.

Release versions of Marlin periodically exhibit bugs. While you can report a bug in the Issue Queue, if you have any coding skills you also have the option to contribute a patch based on your own fork. Minor releases will be made periodically integrating the best patches.

Release Candidates

Occasionally we take the development branch and create a Release Candidate for public testing on the way to a formal version release. We start tagging RC releases for the new version, such as "1.1.0-RC1", "1.1.0-RC2", and so on. Under this scheme the branch "RC" always points to the latest tagged release candidate.

The branch "RCBugFix" starts out with the latest "RC", but any patches that pass inspection will be merged into it over time. (So "RCBugFix" is effectively the latest well-heeled code during a release cycle.)

Sooner or later all the patches that survive in "RCBugFix" graduate to "RC" and we tag a new release candidate. Once we have a release candidate that holds up against aggressive testing by the community we move on to a full release. At that point the release goes into bug fixing mode with occasional point releases.

Current Development

To get involved with the latest **cutting-edge development and testing on Version 1.2 and beyond**, head over to the Marlin Development Wiki. There you can find guidance on the new file layout, obtaining the hardware support package, and how to integrate Marlin with Arduino >= 1.6.7.

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 MarlinDev/dev 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.

For information related to **patching current releases and release candidates (beta releases)** see Reporting Bugs and Contributing here in this wiki.

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.

Patching Bugs In Releases

Report issues in release versions in the Issue Queue for this tree. To contribute patches to release versions or release candidates, use the appropriate "BugFix" branch. For example, make PRs against "RCBugFix" for any patches to "RC" and when 1.1.0 is released, we will have a "BugFix-1.1.0" branch). If you need guidance making Pull Requests, first consult the Github documentation and then ask for help.

• Get the latest release from the Marlin Releases page.
• Before submitting a bug report about RC, check the issue queue and test RCBugFix to see if the issue exists there also.
• Make all PRs against RCBugFix. (Don't make PRs against RC!)
• Report issues and bugs in RC and RCBugFix to the Marlin Issue Queue.

Contributing New Features

For new features you should make your new feature branch from the MarlinFirmware/MarlinDev tree (See Above). But feel free to implement features for 1.1.x versions of Marlin also, as the code has close parity with 1.2.x development, and later point releases may adopt non-disruptive new features over time into the 1.1.x branch.

Merging Commits

If a pull request has many commits, or if you find you have to patch up mistakes in earlier commits, remember that you can use git rebase -i baseBranch to "fixup" commits into a smaller number, and then when you use git push -f to force-update your "origin" repo it also updates the Pull Request!