Skip to content

Latest commit

 

History

History
84 lines (65 loc) · 4.22 KB

CONTRIBUTING.md

File metadata and controls

84 lines (65 loc) · 4.22 KB
copyright
Copyright (c) Runtime Verification, Inc. All Rights Reserved.

K Framework Contributor Guide

Thank you for making a contribution to the K Framework. This document explains the steps that need to be followed to get your changes reviewed, tested and merged into K. If you have any questions about this process or K in general, please get in touch via our Discord Server or Matrix Room.

Opening an issue

If you are using K and want to report something that doesn't work as you expect, the best way to do so is to open an issue against the K repository. Please make sure to include as much relevant information as possible in your issue to help us reproduce it. We will reply to you with any questions we have about the issue, then triage it to get fixed.

Making a change to K

We welcome contributions to K from the community. Because running the K test suite uses our private compute resources, there are a few steps to go through to get your changes tested and merged.

Fork the K repository

For external contributors, please fork the K repository following the Github documentation. Commit any changes you make to a branch on your fork.

Develop your changes locally

The first step is to develop and test your changes locally. Follow the instructions in the K README to build and test the project with your changes included. The most important tests to run are the K integration tests:

$ make -C k-distribution/tests/regression-new --jobs $(nproc) --output-sync

If your changes only apply to documentation, you can skip the testing phase.

Open a pull request

Once you have tested your change locally, push your commits to your fork of K and open a pull request (PR), again following the Github documentation. In the pull request, please indicate what tests you have run locally on your changes (e.g. "I have run the K integration tests locally"). Because this PR is coming from an external fork, the K test suite and CI process will not run. This is expected behaviour. Additionally, please make sure that the commit history in your PR is clean by rebasing any messy or partial commits. Finally, it is important that your commits are based on the K develop branch.

Next, please request a review from a K maintainer on your PR. The last person to modify the files you are changing is a good start, or if you're not sure, tag @tothtamas28 as a fallback.

Once your code has been initially reviewed by a K maintainer, we will approve it to run against our CI test suite. If the tests pass, we will merge the PR and close your original PR. If changes need to be made subsequently to get tests to pass, they will need to be pushed to your original fork branch. For trivial changes, it can be useful if you permit modifications to be pushed to your branch by maintainers.

Licensing

K is licensed under the BSD 3-Clause License. If you make changes to K via a pull request, your changes will automatically be licensed under the same license following Github's terms of service.