Pull Request Guideline - Kernel-GL-HRK/gl-kernel-basecamp-2020 GitHub Wiki

How to work with this repository

  • Don't work on upstream master branch.
  • Treat your personal upstream branch (refer to Branches table) as a base for development.
  • Avoid direct committing to any branch in this repository except your personal branch.
  • Periodically sync your personal branch with master branch (you can directly push such commits).
  • Use dedicated branches in your forks for development - try to keep master and your personal branch intact and synced with the upstream repository.
  • All solutions should be submitted via a pull request.

Pull Requests creation

  • Create PRs from development branches in your forks to your personal branch in this repository.
    • Separate branch (and PR) should be created for each task.
    • These branches should be forked from your personal branch after merging the corresponding task from the master.
  • Try to give descriptive title to PR.
  • Treat the first message of PR discussion as PR description (you can edit it afterwards) and provide an explanation of the work.
  • Apply appropriate label to your PRs to reflect its readiness for review.
    • When applying a new label - remove the previous, so each PR could have the only one label reflecting its status.
  • Use @mentions to ping others if you need some reaction.
  • PR updating: *In general, a pull request is updated through overwriting the existing branch with changed or newly added commits.
    • Don't forget to describe changes by message in PR conversation.
  • PR merging:
    • "Create a merge commit" should be used to clearly show the scope of each task and dependencies in history.

Code formatting

  • Keep sources in dedicated subdirectories under appropriate lesson or practice topic.
  • Source code should be formatted according to kernel coding standards.
  • Try to use meaningful names for modules, their API, source files and in code.
  • Kernel modules should include MODULE_AUTHOR and MODULE_DESCRIPTION.
  • Use checkpatch (instruction).

Formatting patches

  • Commit messages should include:
    • subject line (started from [tags]);
    • descriptive body, separated by empty line;
    • Signed-off-by line (use -s option to git commit)
  • If new exercise, you provide a solution for, is based on another exercise or third-party code, you should commit a clean copy first (don't forget to mention its origin in the commit message) and then commit patch with your changes for this exercise.
  • If original code requires cleaning up (e.g. to conform code standards or to remove unneeded functionality) - do it as separate commit (prior to providing your changes).