Contributing branches and reverting

[roberth]

Motivation

• Explain our branches
• Explain why reverts are good

I consider the latter crucial for agility.

Let's review this in a meeting.

Context

Priorities

Add 👍 to pull requests you find important.

[Ericson2314]

I first learned of this revert style from LLVM. It surprised me at first, but then I came to believe it is good.

[fricklerhandwerk]

Thank you, this is important.

[fricklerhandwerk]

IMHO those should not exist at all, and feature branches should come from forks. Since this documentation is descriptive rather than prescriptive, I won't block that with my desire to discuss this, but I'd still like to discuss it eventually.

[roberth]

Forks in organizations are problematic because they can't be configured to allow contributions from upstream maintainers. We might suggest using personal forks.

[thufschmitt]

I also tend to use feature branches from the NixOS repo because it's the only sane way for having stacked PRs in GitHub (although that's a bit of an edge-case)

[roberth]

Fwiw this makes no claim about the lifecycle of the feature branch. Any branch that isn't a maintenance branch or - I guess - a proof of concept should be short-lived.
I don't think we should focus any attention on these branches for the time being, while we have bigger fish to fry, such as the again increasing PR queue, and stabilization.