Currently there is no way to report issue in the github project, however supported @SiliconLabs customers can report cases individually.
There is no strong requirement for now, but user are encouraged to track their changes by prefixing branch names with meaningful prefixes such as "feature" or "bugfix".
If the change refers to existing context id, feel free to add it.
| Sl No | Type of Branch | Use Case | Example |
|---|---|---|---|
| 1 | Feature Branches | For developing new features or functionalities. These branches are often used for longer-lived work and may be merged into the main branch when completed. | feature/user-authentication |
| 2 | Bugfix Branches | For addressing specific issues or bugs. Bugfix branches are created to isolate and fix a problem, and they're often merged back into the main branch (or a release branch) once the fix is verified. | bugfix/GH-1234-fix-for-UMB-crash |
| 3 | Experimental Branches | For highly experimental or uncertain work that may or may not make it into the main codebase. These branches allow team members to collaborate on new ideas without affecting the main development flow | experimental/GH-1234-migration-of-core |
| 4 | Documentation Branches | For creating or updating documentation, such as README files, user guides, or API documentation. Separate documentation branches make it easier to manage documentation changes independently from code changes | docs/GH-1234-updates-readme |
| 5 | Refactoring Branches | For making significant changes to the codebase that don't add new features or fix bugs but improve the code's structure, readability, or maintainability. Separate refactoring branches help keep refactoring efforts organized | refactor/GH-1234-refactors-authentication-module |
| 6 | Test Branches | For adding or modifying test cases. These branches allow for the isolation of test-related changes and help maintain a robust testing suit | test/adds -thermostat-test-cases |
Commit message should not exceed 50 characters.
Within your commits, you can include a commit description, allowing to add even more detail / context as to what you did.
Add an empty line underneath the commit message, and begin writing a description from line 3.
Example:
GH-XYZ: Fix issue with login button not showing.
- Update login form validation
- Update login styling for showing the button
| Sl No | Commit Message Examples |
|---|---|
| 1 | Add support for thermostat cluster |
| 2 | Remove python2 deprecated dependencies |
| 3 | Update rust dependencies to latest version |
| 4 | Fix portable runtime crash |
| 5 | Refactor core components into rust |
| 6 | Add unit tests for thermostat cluster |
What to consider while raising a Pull Request
- Pull request naming
Context: <message clearing explaining what commit does>
- Write a useful description in the “details” section of the pull request. i.e, mention the root cause of problem and approach of the solution.
- Max size of Pull request should be < 300 lines (excluding autogenerated code)
- If Changes are greater than 300 lines, split the changes into logical groups using multiple PRs.
- Pull Request should be raised only after successful execution of the existing unit Test cases.
- One Pull Request should address only one issues (don’t combine multiple changes, this applies for indentation changes as well)
- Don’t change the code while reviewing, use "Draft" state for asking developers not to review the code or to block merging of code.
- Design the code in a modular fashion that allows functional tesing.
What to consider while reviewing a Pull Request
- Does the code has successful build?
- Does the code follow unify coding guidelines?
- Does the code meet its objective / acceptance criteria?
- Does the code have unit test and documentation included?
- Does the code need any refactoring, considering security, performance or simply ease of reading?
- Use "Suggestion" feature which allows you to add a code suggestion directly into the comment, which can instantly be accepted and committed from within the PR.
- Write clear comments. Describe the issue, why you don’t agree (mistakes, errors, violations against conventions, performance risk, security issues, etc.), and propose other solutions to simplify and improve the code.
- If any of the comments need to be addressed mandatorily, mark the pull request as “Draft”
All contributors have to manually run the unit test locally before raising the Pull request.
- Inside docker, build with -DBUILD_TESTING=ON.
- Then “ninja” and “ninja test” (this command runs all the tests.)
If you want to test individually you can do by running test executables from shell
Build and unit tests are run from contributor fork using github actions.