Please label incoming tickets accordingly according to these rules:
- Add the “bug” label to things that you think must be fixed urgently. Please don’t use this label for bugs that do not severely impede Flycheck’s functionality.
- Add the “needs review” label to new bugs and pull requests that need to be reviewed.
- Add the “beginner friendly” label to really easy things. If you add this label please also add a comment that outlines a possible solution.
- Add “blocked” to bugs that need further comment or help from the reporter, and to pull requests that need to be improved.
- Add “needs help” to anything that no contributor will work on, to mark the issue as available for external contributors and inform users that we will not work on the issue.
- Add “windows only” for bugs that appear to only affect Windows operating systems.
If you’d like to review a bug or pull request please assign the corresponding ticket to you.
In issues for specific languages that Flycheck support please mention the corresponding language team if one exists.
Our Git workflow is simple:
masterbranch is always shippable.
- Every feature and every non-trivial change goes through a pull request.
GitHub calls this the “GitHub Flow” and has a very nice visual guide for this model.
Our workflow implies a couple of rules about which branches to push code to:
- Please commit new features, larger changes and refactorings and updates to documentation to separate branches and open a pull request for review and discussion.
masterbranch is protected. Only owners can push directly to it. Everyone else needs to open a pull request. Github requires maintainer approval and passing Travis CI tests before a pull request can be merged to master.
When creating a new branch please use a descriptive name to communicate the
purpose of the branch to other developers and maintainers.
not a great name, but
Pull requests reviews¶
We review all pull requests, and require two different kinds of approval:
- At least one maintainer must approve the idea and direction with a
- At least one contributor (maintainer or otherwise) must approve the implementation by leaving an approved pull request review, and no contributors must have requested changes.
As a maintainer¶
- Consider whether you personally think that the change is a good addition to Flycheck.
- Weight the expected benefits and impact of the feature against the expected complexity.
- Check whether the pull request complies with our style guide, but don’t go too much into technical details.
- Don’t review for technical details. It’s the idea and direction that counts.
If you would like to see the pull request in Flycheck leave a
The LGTM.co service will look for these comments and unlock the pull request
once enough maintainers approved it. The exact rules are in the
file, the list of maintainers is in the
As a contributor¶
- Check the technical implementation.
- Consider the impact on syntax checking for a language.
- Check whether the tests pass.
- Check whether the PR complies with our style guide.
- Challenge the technical implementation of a pull request, and ask questions about dubious code.
- Consider whether there might be a simpler approach or a better solution to the problem that the PR solves.
If you find any issues please leave a pull request review that requests for changes. Please try to leave an inline comment wherever possible and try to suggest a better solution, to make it easy for the PR author to discover and fix the issues.
If you didn’t find any issues leave a pull request review that approves the changes.
In doubt request changes first and let the PR author explain their intention and implementation. You can still approve the review afterwards if you are satisfied.
Any contributor may merge approved pull requests. Our protection rules for the
master branch ensure that only approved pull requests can be merged, so if
the “Merge” button is green go ahead and press it :)
We require proper merges for pull requests, to preserve the fact that a change came from a pull request in the git history and to retain any commit signatures that may exist. As such you can’t squash-merge or rebase-merge through GitHub’s UI.
Before merging please take an extra look at the commits to make sure that the commits were properly squashed and have good commit messages.
Ask the contributor to improve the commit messages and squash the commits first, by requesting changes with a pull request review.
Tooling and Services¶
In addition to Github where we host code and do code reviews we use a bit of extra tooling and some 3rd party services for Flycheck:
- ReadTheDocs hosts http://www.flycheck.org and automatically rebuilds it on every change. It works mostly automatically and requires little configuration.
- Travis CI runs our tests after every push and for every pull request.
It’s configured through
- LGTM handles the pull request approval process through
LGTMcomments. It’s configured through
.lgtm, the list of maintainers that may approve pull requests is in the
- CLA assistant checks signatures to our CLA and allows contributors to sign the CLA through their Github account.
All maintainers have administrative access to these services so in case of an issue just contact them.
Administrative processes are tedious and time-consuming, so we try to automate
as much as possible. The
maint/ directory contains many scripts for
make -C maint/ help provides an overview over all
Most of these scripts require Python 3.5 and additional Python libraries. On OS
X it is recommended that you use Homebrew to install the latest Python version
brew install python3. On Linux you should be able to obtain Python 3.5
from the package manager of your distribution.
To install all required libraries run
make -C maint init. We recommend that
you use virtualenv to avoid a global installation of Python modules.
init will warn you if you do not.
Versioning and releases¶
We use a single continuously increasing version number for Flycheck.
Breaking changes may occur at any point.
Please feel free to make a release whenever you think it’s appropriate. It’s generally a good idea to release when
- you fixed an important bug that affects many users,
- there are a couple of new syntax checkers available,
- there’s a major new feature in
In doubt just make a release. We aim to release early and frequently. If anything breaks anything we can just publish another release afterwards.
First, check that
- you are on
- your working directory is clean, i.e. has no uncommitted changes or untracked files,
- all commits are pushed,
- and Travis CI passes for the latest commit on
If all is good a new release is a simple as
$ make -C maint release
This runs the release script in
maint/release.py. If any of the above
requirements isn’t met the release script will signal an error and abort.
The release script bumps the version number, commits and tags a new release, and pushes it to Github.
The tag is signed; you must configure Git for signing commits and tags before you make a release the first time. After pushing the new release to Github, the script bumps the version number again, to the next snapshot, and commits the changes again.
Once the script is completed please
- Edit the release information on Github and add a short summary about the release. Don’t forget to add a link to the complete changelog and upload the package TAR file.
- Enable the new release on the ReadTheDocs versions dashboard.
- Announce the new release in our Gitter channel, on emacs_flycheck Twitter and wherever else you see fit.
To propose a new maintainer open a pull request that adds the user to
doc/community/people.rst. The pull request is subject
to the same rules as all other pull
requests. Notably it goes through the same approval process.
Once merged please also
- add the new maintainer to the
Maintainersteam of the Github organisation. This does not award additional privileges, it’s just to support
@flycheck/maintainersmentions for the sake of convenience,
- invite the new maintainer to the internal Maintainers channel on Gitter,
- and announce the new maintainer on Flycheck’s Twitter account.