Skip to content

vsomeip Contribution Process

Jump to bottom
Duarte Fonseca edited this page Sep 5, 2024 · 7 revisions

Introduction to vsomeip Contribution Process

There are two main methods to propose changes or extensions to vsomeip:

  • If you have an idea or a question you can create a Discussion in GitHub.
  • If you have a bug you can create an Issue in GitHub.
  • If you already have prepared changes or extension that you think would be interesting for COVESA to include in vsomeip then you can create a Pull Request (PR).

All contributions must follow the COVESA contribution guidelines.

The vsomeip project has regular meetings Monthly on the third Monday at 16:00 CET / 10:00pm ET / 7am PT (Community Calendar). In the meetings Pull Requests (PRs) and Discussions are discussed and, if a Pull Request is accepted, a decision to merge the PR will be made. Everyone interested is welcome to join the meetings.

Creating a Pull Request towards vsomeip

This is the typical workflow for preparing a pull request. A GitHub account is required.

  1. Create a personal or company fork of the vsomeip repository.
  2. Clone the forked repository into your local development environment.
  3. Set up your local development environment, see README.md for some guidance. See vsomeip in 10 minutes for an overview.
  4. Create a local branch based on the vsomeip master branch to use for the proposed changes.
  5. Introduce the wanted changes or extensions in your local development environment.
  6. Create a commit and upload to your own fork.
  7. In the GitHub UI, create a Pull Request from your fork to the master branch of the vsomeip repository.
  8. Validate that automatic build checks for the PR succeed.
  9. The maintainers will verify that your changes fulfill vsomeip Continuous Integration requirements. For that internal testing will be carried.

The team is analysing the possibility of introducing automatic testing on new PR's.

Handling of the created Pull Request

  1. The PR creator shall follow up on any comments or questions received on the Pull Request.
  2. The PR will be discussed at one of the next vsomeip monthly meeting and/or between meetings via the COVESA #vsomeip Slack Channel (https://covesacommunity.slack.com #vsomeip). It is preferable if the PR creator can participate and give a quick introduction on the rationale for the change.
  3. Unless trivial, PRs shall typically be open for at least a week before merging is considered, to give time for comments.
  4. If needed, the PR creator needs to refactor the PR to address received comments and remarks.
  5. If all comments and concerns have been sorted out and no-one objects merging, a decision will be made in the meeting to merge the PR. It is not guaranteed that all PRs will be accepted. The vsomeip meeting may reject and close Pull Requests.
  6. A vsomeip maintainer will perform the final merge.

Guidelines and Recommendations

This section includes general guidelines and recommendations for anyone interested in contributing to vsomeip.

All contributions must follow COVESA contribution guidelines

COVESA has defined contribution guidelines.

Every contribution (commit) must carry the following sign-off line with your real name and email address:

Signed-off-by: Firstname Lastname <[email protected]>

By supplying this sign-off line, you indicate your acceptance of the COVESA Certificate of Origin.

If using git command line you can add a sign-off by using the -s argument when creating a commit.

For certain files (if newly created) it is requested that a copyright and license statement is added as file header. This currently applies to the following file types:

  • source and header files (*.cpp, *.hpp)
  • cmake files (CMakeLists.txt)

Those files shall have copyright statement of the following form, inspired by the Eclipse generic copyright header. Copyright/License-statement may also be added to other files if considered relevant.

# Copyright (c) {year} Contributors to COVESA
#
# This program and the accompanying materials are made available under the
# terms of the Mozilla Public License 2.0 which is available at
# https://www.mozilla.org/en-US/MPL/2.0/
#
# SPDX-License-Identifier: MPL-2.0

Where {year} is the year the file was originally created. No need to update or append new years or a range of years later.

Avoid backward incompatible changes

Sometimes changes may break backwards compatibility. This should only be done if there is a good reason. Merging can be delayed, as maintainers may decide to wait and test with the change until the next major release is prepared.

Getting Support

To avoid time consuming refactoring it could, for bigger contributions, be relevant to ask vsomeip if the wanted changes seems to be reasonable and likely will be accepted by vsomeip. Create an Discussion and describe what you intend to do and ask for feedback. You can also create a draft pull request at an early stage and ask for comments.

Clone this wiki locally