Skip to content

Latest commit

 

History

History
146 lines (97 loc) · 8.49 KB

CONTRIBUTING.md

File metadata and controls

146 lines (97 loc) · 8.49 KB
Raw

Contributing Guide

Welcome! We love receiving contributions from the community, so thanks for stopping by! There are many ways to contribute, including submitting bug reports, improving documentation, submitting feature requests, reviewing new submissions, or contributing code that can be incorporated into the project.

This document describes the Embedded Artistry development process. Following these guidelines shows that you respect the time and effort of the developers managing this project. In return, you will be shown respect in addressing your issue, reviewing your changes, and incorporating your contributions.

Table of Contents:

  1. Code of Conduct
  2. Important Resources
  3. Questions
  4. Contributing to the Project
    1. Continual Need: Documentation
    2. Dependencies
    3. Development Process
    4. Building the Project
    5. Adding New Tests
  5. Community

Code of Conduct

By participating in this project, you agree to abide by the Embedded Artistry Code of Conduct. We expect all contributors to follow the Code of Conduct and to treat fellow humans with respect.

Important Resources

This project is managed on GitHub:

Questions can also be submitted on the Embedded Artistry website and in the Embedded Artistry Forum.

Useful Documentation:

Embedded Artistry blog posts related to this project:

Questions

Please submit your questions in the following ways:

New to Open Source?

If you've never worked with an open source project before, please check out our Open Source Contribution Guide, which contains information on:

  • Resources for people new to open-source development
  • How to find something to work on
  • How to report issues
  • Branching and PR guidelines for our projects
  • Style guidelines for our projects

Contributing to the Project

If you're interested in contributing = to this project, read on! Don't know where to start? Take a look at the Open Source Contribution Guide section for information on finding beginner-friendly issues on our projects.

Please review the following guides to learn about our development process:

If you have any questions about this process, please ask us for help!

Continual Need: Documentation

Should you have a suggestion for the documentation, you can open an issue and outline the problem or improvement you have - however, creating the doc fix yourself is much better! By creating a new issue (or commenting on a related existing one), you let others know what you're working on. If you're making a small change (typo, phrasing) don't worry about filing an issue first - just open a Pull Request.

I currently need the most help with improving the libc in-source Doxygen documentation and commenting. If you would like to help, please select a header in the include/ folder and add Doxygen style comments to functions with no documentation.

For large fixes, please build and test the documentation before submitting the PR to be sure you haven't accidentally introduced any layout or formatting issues. To generate the Doxygen documentation, run:

make docs

You can find the resulting output in buildresults/docs folder.

Dependencies

The dependencies for Embedded Artistry's standardized Meson build system are described on our website.

In addition to those dependencies, you will need the following for this repository:

  • git-lfs is used to store binary files

Development Process

master contains the latest code for this project, and new versions are tagged nightly.

Please branch from master for any new changes. Once you are ready to merge changes, open a pull request. The build server will test and analyze the branch to ensure it can be safely merged.

Building the Project

This project uses Embedded Artistry's standardized Meson build system. Complete instructions can be found on our website. You can also build using CMake, eg cd build && cmake -GNinja .. && ninja.

Adding New Tests

If you add code you need to add tests! We’ve learned the hard way that code without tests is undependable. If your pull request reduces our test coverage because it lacks tests then it will be rejected.

This project uses CMocka as the testing framework.

Please follow these guidelines:

  • New tests should be added to the test/ directory tree
    • If you are adding a new function to an existing module, please add it in that module's tree
      • e.g. string/, stdlib/, ctype/
    • If you are adding a new module or a function in a new module, please create that directory and add the file there.
  • Each function should have its own tests in its own C file.
  • Each module should have a C file which coordinates the tests.
  • When adding a new test, add the following to the relevant test coordination file:
    • An extern function declaration: extern int memcpy_tests(void);
    • A call to this test function: overall_result |= memcpy_tests();
  • When adding a new module:
    • Please copy the test coordinator style from an existing module
    • Add an extern function declaration in main.c: extern int ctype_tests(void);
    • Add a call to the test coordinator in main.c: overall_result |= ctype_tests();

Community

Anyone interested in active conversation regarding this project should [join the Embedded Artistry community]https://embeddedartistry.com/community/embedded-artistry-oss/).

You can also reach out on Twitter: mbeddedartistry.