github.com/google/syzkaller@v0.0.0-20240517125934-c0f1611a36d6/docs/maintaining.md (about)

     1  # Maintainer's Guide
     2  
     3  ## Linear history
     4  
     5  We preserve linear history and have merge commits disabled in repository settings.
     6  Pull requests (PR) have only 2 options:
     7  - **Rebase and merge**\
     8    This is preferred if all commits in the PR are properly squashed/fixed already,
     9    as it preserves commits in the PR (takes all commits in the PR as is and adds them
    10    on top of the master HEAD).
    11  - **Squash and merge**\
    12    This is preferred if the PR contains fix ups as separate commits and/or other clutter
    13    in commit organization (squashes all commits in the PR into one commit and adds it
    14    on top of the master HEAD, also allows to edit commit subject/description).
    15  
    16  ## PR checks (CI)
    17  
    18  `cla/google` check needs to pass before merging.
    19  
    20  CI testing generally needs to pass before merging.\
    21  Exceptions may be infrastrcture flakes (especially in external services: `codecov`, `ci/fuzzit`);
    22  one-off timeouts/OOMs (but not if this PR itself makes them much more frequent).
    23  All static checking warnings and testing errors are considered hard errors.
    24  
    25  ## Tests
    26  
    27  Adding tests for new code and bug fixes is generally encouraged. Ask contributors to add tests.
    28  
    29  However, some code is easier to test, while some is harder. Some examples of cases where
    30  it's easier to add tests (should be added): abstract functionalities without external dependencies
    31  (e.g. parsers, data transformations, calculations); code with established testing infrastrcture
    32  (adding new tests is just adding one more of the same). Examples of cases where it's harder
    33  to add tests (may be not added, but still welcome if one wants to go above and beyond):
    34  code with external dependancies that are not easy to fake out (qemu, kernel, image, etc);
    35  code without established testing infrastrcture where adding one test would require building
    36  the whole infrastrcture first.
    37  
    38  ## Use your judgement
    39  
    40  There are no strict rules for reviews/ownership at the moment. Use your judgement.
    41  
    42  If you are maintaining a particular area of the project (e.g. support for one OS),
    43  it is OK to merge your own changes without further review (especially smaller and
    44  if CI gives green light). It's also OK to review and merge changes to other parts
    45  of the project. But loop in other maintainers if you don't feel confident or need
    46  additional feedback/review.