ci: enable gitlint

[gmarull]

Applied rules:

• Built-in rulles: all defaults, except:

  • Do not ignore cleanup commits (conflicts with CC2)
  • Do not ignore merge commits (they will fail with the rule below)
  • Custom title regex, enforce area[/subarea]: description, e.g. docs: add new GSG guide, drivers/qspi: fix quad-line access, etc.

• Contrib rules:

  • CC1: require Signed-off-by (DCO)
  • CC2: no cleanup commits (fixup!, squash!, amend!)

Ref. https://jorisroovers.com/gitlint/latest/rules/

[jwise]

LGTM. Re:

note we should avoid using branches upstream for PRs; otherwise every upstream fetch may pull random stuff

I find it mostly convenient with small numbers of developers (this is how X1Plus works, for instance, and it makes it more convenient for multiple people to be committing to / hacking on a WIP branch that is not ready to merge yet) but I guess it does not scale for large numbers of developers. Luckily we do not have to decide that for sure here :)

[jwise]

LGTM.

[gmarull]

LGTM. Re:

note we should avoid using branches upstream for PRs; otherwise every upstream fetch may pull random stuff

I find it mostly convenient with small numbers of developers (this is how X1Plus works, for instance, and it makes it more convenient for multiple people to be committing to / hacking on a WIP branch that is not ready to merge yet) but I guess it does not scale for large numbers of developers. Luckily we do not have to decide that for sure here :)

I find upstream branches useful if there's a public-shared development topic not in main yet ("topic" branches), for other stuff forks are much cleaner, also the standard way to contribute regardless of membership level. It's also easy to check out a PR without touching remotes, git fetch upstream pull/N/head:my-local-branch.