How to fix bugs for Umbraco
This is a guide to how you can contribute back to Umbraco with fixing bugs and code changes.
Although there is a crack team of ninjas behind the project not all issues can be resolved in a time which you may deem speedy enough.
Who can fix bugs
With the move of Umbraco to Mercurial as a source control system it's easy for anyone in the community to contribute back with bug fixing.
All pull requests that are sent from the community will be reviewed by the Umbraco core to ensure that they meet the committer guidelines which will be outlined below. Any pull request which is submitted that doesn't meet the guidelines will not be accepted back into the core.
Creating forks
If you are looking to fix bugs within Umbraco then you need to create a fork of the Umbraco code in which you can do your changes and then produce a pull request. To do this you need to:
- Enter a name for the fork and a description and click Save
Note the rest of this document is going to assume you're familiar with working with Mercurial in terms of cloning repositories, etc. Refer to the appropriate Mercurial documentation if you aren't sure what to do next
Preparing a pull request
The following section is going to cover what the Umbraco code reviewers will be looking at when they are reviewing a pull request.
Named branches
When you are working in your own clone you have the choice of working in your own named branch or working aginst one of the existing branched. Generally speaking pull requests are expected to have their fixes against one of the named branches which are in the core Umbraco repository.
There are a few reasons for this:
- We know exactly what version of Umbraco your fix(es) are targetting
- It keeps the branch list in Umbraco small
There is a small exception to this rule, when a bug fix requires extremely large amounts of code refactoring. When you are doing a change that requires its own named branch then the named branch much be in the format of release-issue-id, for example, 4.6.0-1234.
Associating with issues
Any pull request that is submitted must list out the issues which it is resolving. All changes must be associated with a work item, a pull request won't be accepted unless there are work items which it is fixing.
If you are fixing something that doesn't already have an issue which is listed in the CodePlex issue register then you will need to create one.
Any pull request which doesn't have associated work items will be declined.
Unit tests
Umbraco has a large suite of unit tests covering a good portion of the codebase. Any pull request should not cause any the unit tests to fail. Where possible it is expected that the new code has supporting unit tests to ensure the bug is resolved.
Keeping in sync with the core repository
When a pull request is submitted it should be syncronized in line with the core repository, with your changes representing the tip tag (meaning it was the last commit to the repository) and all merge conflicts should have been resolved.