Skip to content

nixpkgs branch protection rules: prevent creation of new branches! #118

@wolfgangwalther

Description

@wolfgangwalther

More often than not, branches are created in the nixpkgs repo by accident, when they should actually be created in committers forks.

This leads multiple problems:

  • The fork's "delete after merge" policy doesn't kick in.
  • The nixpkgs repo's branches are cluttered wild old, abandoned stuff.
  • Sometimes people accidentally create names matching an existing branch protection rule. Those branches can't be cleaned up (by ordinary committers like me, at least). Examples: staging.patchShebangs, release-18.09-firefox64, staging-patchelf, .. there are more.

Imho, there are exactly 3 reasons to have branches in the nixpkgs upstream repo itself:

  • channel branches starting with nixpkgs- and nixos-.
  • backport branches, created by CI starting with backport-.
  • development branches: master, release-xx.yy, staging (...), haskell-updates, python-updates...

There is a bit of inconsistency in the development branches right now. For example, we also have r-updates, which is a protected branch, but is not listed in ci/request-reviews/dev-branches.txt (and the relevant workflows). And we have perl-updates, which is not a protected branch, but seems to be used in the same way.

To prevent us from introducing more of that, I would like to suggest the following:

  • Create a new branch protection rule, which matches all branches and does not allow branch creation. The backport app and the release team would be added as those who can bypass this rule.
  • Somebody with owner permission to go through the branch list and look for those accidentally protected branches (mentioned above, there are more - they all start with a prefix of release/staging, two also with nixos-test-) and delete them.
  • Clarify the status of r-updates and perl-updates - and possibly other "development branches" that might be needed to collaborate together on a topic. Those should all follow the same CI principles and be protected similarly. For example that means they can be cherry-picked for backports from etc.

We'd then be fading out the still open PRs over time, by deleting the relevant branches when the PR has been closed/merged.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions