Move development workflows to GitHub about unit HOT 1 OPEN

The team should decide on a code review and merge workflow and configure GitHub to enforce it (e.g., the Unit team prefers a linear history, so merge commits are disabled in our repo settings, but we're still debating whether GitHub's "Squash and Merge" is acceptable or if we'd rather have developers manually prepare their final patch.)

My views on why for me squashing is a non-starter are well documented, but I'll just summarise it as

If a developer has N commits, that should be committed as N commits, then they should be merged as N commits.

I didn't go to the trouble of splitting commits out only to have them all munged back together. This would also be problematic for a pull request with commits from different authors...

or should they be developed in a personal fork of the repo? (The Unit team prefers the latter to keep the upstream repo clean, and to eat our own dogfood with regard to external contribution workflows.)

This. The main repository should not be polluted with random branches. Make use of the D in DVCS.

Tags are weird.

We should switch to using annotated tags to point to a version bump, rather than the currently somewhat weird

1.31.1          Generated Dockerfiles for Unit 1.31.1.
1.31.1-1        Merged with the default branch.

I.e

1.32.0        Unit 1.32.0

That then points to a commit that updates the version. Maybe it includes the above, or maybe it is simply the bump in version in version.

So when you checkout a version, that is everything for that version, e.g at least everything that would be in a .tar.gz for that release.

In case you're wandering about annotated tags, from the git-tag(1) man page

Annotated tags are meant for release while lightweight tags are meant
for private or temporary object labels. For this reason, some git
commands for naming objects (like git describe) will ignore lightweight
tags by default.

That last sentence means this

$ git describe 
fatal: No annotated tags can describe '88854cf14688286f835f7177c6bfaa17f1962f67'.
However, there were unannotated tags: try --tags
$ git describe --tags
1.31.1-24-g88854cf1

Lightweight tag as used by Unit

$ git show --no-decorate 1.31.1
commit 09ab626b13a027a4d3f8b5dcdcdba3e8eee76977
Author: Andrei Zeliankou <[email protected]>
Date:   Tue Oct 17 14:15:38 2023 +0000

    Generated Dockerfiles for Unit 1.31.1.


...

Example of an annotated tag as used by unit-wasm

$ git show --no-decorate v0.3.0
tag v0.3.0
Tagger: Andrew Clayton <[email protected]>
Date:   Thu Oct 19 19:42:38 2023 +0100

unit-wasm 0.3.0

commit 01c43784ec53aa1ff22aca7e7ae6f18b4591b514
Author: Andrew Clayton <[email protected]>
Date:   Thu Oct 19 19:35:12 2023 +0100

    unit-wasm 0.3.0
    
    Signed-off-by: Andrew Clayton <[email protected]>


...

from unit.