GENIVI is an Open Source project and follows Open Source "best practices." This means that it is easy to contribute to GENIVI in a number of ways. This public wiki page goes into some detail on the various methods in which your contribution can be best formatted for easy acceptance. Not following specific requirements may lead to proposals being rejected. Please refer to GENIVI's contribution guidelines for more.
One can contribute a new project (see New Project Contribution below) or to an existing GENIVI project. There are a number of active projects available in GitHub. Contributing code to one of these projects is as easy as cloning the repo and
- sending a pull request through GitHub (preferred process)
- if you cannot access GitHub, sending a patch to the mailing list which is a similar, if not identical, process found in other open projects.
Note that you'll have to abide by the license that the code is released under, but most of the time that is the Mozilla Public License 2.0 which is a Free Software license, so it is easy to work with. Take the time to understand the license and that will make your contribution process easier.
Its important that you ensure you have permission to submit code to the GENIVI project. If your company is a GENIVI member and has signed the CLA, check with your company for okay first. Non-members can submit code by following the Open Source process.
- Each patch must contain only 1 logical change and hence smaller the patch, the better. Among other benefits, it's easier to review.
- Patches that have been tested against the target are likely to build on the maintainers machine, pro tip: test your patch
- In some cases you'll need to include a "developer certificate of origin"
- Requirement: for commit messages, follow these rules to the best of your abilities.
- Requirement: if you're from a company that has a signed CLA with GENIVI, you'll need to be on the CLA contributors list or a maintainer will not be able to accept your patch (CLA FAQ)
- Requirement: include a "Signed-off-by:" line. Use git format-patch with the -s flag for example
For most projects we recommend Rules for Commit Messages. For GDP the rules are required.
The goal with this checklist is make patches easier to contribute by providing a minimum of what is expected.
Different project maintainers deal with patches differently so contact the project's mailing list for their patch acceptance policy.
Pull request through GitHub
Pull Request is the preferred process to submit code to GENIVI. The process looks like this;
- Use the standard GitHub process for creating pull requests.
- Please provide some form of explanation for what the patch does and why it is needed.
- The mailing list is often a good place to discuss patches
- The requirements above also apply; if you use the CLA ensure you're on it, sign your commits (see Patch process)
Patches sent through GENIVI mailing lists
The preferred submission process is through GitHub PR but it is also possible to submit patches through the appropriate mailing list. GENIVI projects use the following best practices for submitting patches through mailing lists:
- Start the subject line with the tag: [PATCH]. Multiple patches part of the same group are usually numbered, e.g. 2/10 (meaning second patch out of 10), and if needed patches are versioned. Here is an example from LKML
- Please provide some form of explanation for what the patch does and why it is needed. The mailing list is often a good place to discuss patches
- Use at least diff -u to create your patch, different lists may prefer different formats so it's good to check beforehand
- Attach your patch as an attachment to your email, some mailers mangle white space
- Adding the patch in the email for inlined discussion is a prerogative of the maintainer
See also: Git Email Setup for tips on setting up email for working with patches in a corporate environment. You can also view the Linux kernel patch process which GENIVI has tried to follow when designing its policy.
New Project Contribution
You can contribute a project to be hosted under GENIVI's umbrella, if your project meets the criteria specified here. The process is straight-forward and is outlined here;
- Fill in the required information in GENIVI's project proposal form. A Google form is provided for convenience.
- Mail the project to GENIVI's Open Source projects list: firstname.lastname@example.org
- A project approval process occurs inside GENIVI's OSS office
After those steps are complete GENIVI begins the code launching process.
- Code scanning is done in conjunction with the License Review Team in FOSSology: https://fossology.genivi.org/
- Documentation on the accepted component is delivered and hosted on GENIVI wiki and web site
- Additional infrastructure is created based on need -- issue tracking, document hosting, git repositories, mailing list
- Individuals are assigned to maintain the given infrastructure used to support components, i.e. the git repo, the documents, the issues on a per project basis
SPDX license tags
GENIVI and many companies require the use of SPDX license tags to identify individual files which are part of a larger component. This is done to ensure compliance with all FOSS licenses as well as to provide help in determining provenance. Please use a tag exactly like this in your source code, please note whitespace;
For more information see GENIVI's Public Licensing Policy
Any non-trivial project has bugs. GENIVI hosts an open issue tracker which is used by some projects to hold new features and other easy tasks for those new to the project. Here is a list of issues tagged "new feature" or "improvement" for example: list of "improvement" and "new feature" issues.
There are also TODO pages, like this one for the Browser-PoC todo list. You'll see that the list shows the type of enhancement, its difficulty, and a URL to the issue tracker so you can claim the bug.
Good documentation is key to the success of any project and GENIVI is no exception. GENIVI strives to have good documentation and it can often be found in the GENIVI project pages. If you find issues or have improvements to the documentation, send a change to the relevant mailing list, I'm certain it will be welcomed. This wiki too holds a lot of documentation both in the form of tutorials and in the form of requirements. Looking into this wiki and using it as a resource in combination with the code repositories makes and effective set of tools to move a project forward and creates valuable artifacts which remain open.
Anyone can edit this wiki, all you have to do is register.