Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docs: Add development branch section #9119

Open
wants to merge 1 commit into
base: mbedtls-3.6
Choose a base branch
from
Open

docs: Add development branch section #9119

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
10 changes: 10 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,7 @@ More details on all of these points may be found in the sections below.
- [Sign-off](#license-and-copyright): all commits must be signed off.
- [Tests](#tests): please ensure the PR includes adequate tests.
- [Changelog](#documentation): if needed, please provide a changelog entry.
- [development](#development-branch): please ensure the PR is against the development branch.
- [Backports](#long-term-support-branches): provide a backport if needed (it's fine to wait until the main PR is accepted).

Coding Standards
Expand Down Expand Up @@ -53,6 +54,15 @@ It would be highly appreciated if contributions are backported to LTS branches i
The list of maintained branches can be found in the [Current Branches section
of BRANCHES.md](BRANCHES.md#current-branches).

development branch
------------------

development branch is where all development happens. Some PRs will be backported into the LTS branches, but not all. So all PRs must first start with development. We won't merge a PR into development if we want backport PRs and they are not present. Very specifically, gatekeepers should merge all PRs at the same time. 

Now, some people will create the backports at the same time as the main PR. If changes are required, this means extra work.

It is fine to wait until we are happy with a PR before creating backports. But it's usually best to start with a PR against development (obviously there are special cases of issues that are only in an LTS branch, but ignoring that for the sake of a generally applicable rule) and then create backport PRs if required or requested. 
Comment on lines +60 to +64
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all seems like it's spending a lot of effort providing information that people don't really need. development is the default branch for Git and on GitHub, so that's what you'll get when you clone the repository and that's what you'll target when you make a pull request. Backports need a discussion, but they already have their own section.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We clearly need something, since at least one person didn't find what we currently have straightforward enough. However, I'm not sure that my rambling GitHub comments are the best fit for the documentation here: I'm very happy for others to suggest wording


Tests
-----
As mentioned, tests that show the correctness of the feature or bug fix should be added to the pull request, if no such tests exist.
Expand Down