From 93dbb698b3effe489d307dd7b50200e468545ce7 Mon Sep 17 00:00:00 2001 From: Raito Bezarius Date: Sun, 19 May 2024 16:58:41 +0200 Subject: [PATCH] chore: remove incorrect maintainers/*.md documentation Fate has something different in store for the release process, backporting process and the general maintainer documentation. See https://git.lix.systems/lix-project/lix/issues/260. Change-Id: I626686ff4059aee22a3ab1664b52581b2dbf6ed7 Signed-off-by: Raito Bezarius --- maintainers/README.md | 146 ------------------------ maintainers/backporting.md | 12 -- maintainers/release-process.md | 196 --------------------------------- 3 files changed, 354 deletions(-) delete mode 100644 maintainers/README.md delete mode 100644 maintainers/backporting.md delete mode 100644 maintainers/release-process.md diff --git a/maintainers/README.md b/maintainers/README.md deleted file mode 100644 index 0d520cb0c..000000000 --- a/maintainers/README.md +++ /dev/null @@ -1,146 +0,0 @@ -# Nix maintainers team - -## Motivation - -The team's main responsibility is to set a direction for the development of Nix and ensure that the code is in good shape. - -We aim to achieve this by improving the contributor experience and attracting more maintainers – that is, by helping other people contributing to Nix and eventually taking responsibility – in order to scale the development process to match users' needs. - -### Objectives - -- It is obvious what is worthwhile to work on. -- It is easy to find the right place in the code to make a change. -- It is clear what is expected of a pull request. -- It is predictable how to get a change merged and released. - -### Tasks - -- Establish, communicate, and maintain a technical roadmap -- Improve documentation targeted at contributors - - Record architecture and design decisions - - Elaborate contribution guides and abide to them - - Define and assert quality criteria for contributions -- Maintain the issue tracker and triage pull requests -- Help contributors succeed with pull requests that address roadmap milestones -- Manage the release lifecycle -- Regularly publish reports on work done -- Engage with third parties in the interest of the project -- Ensure the required maintainer capacity for all of the above - -## Members - -- Eelco Dolstra (@edolstra) – Team lead -- Théophane Hufschmitt (@thufschmitt) -- Valentin Gagarin (@fricklerhandwerk) -- Thomas Bereknyei (@tomberek) -- Robert Hensing (@roberth) -- John Ericson (@Ericson2314) - -## Meeting protocol - -The team meets twice a week: - -- Discussion meeting: [Fridays 13:00-14:00 CET](https://calendar.google.com/calendar/event?eid=MHNtOGVuNWtrZXNpZHR2bW1sM3QyN2ZjaGNfMjAyMjExMjVUMTIwMDAwWiBiOW81MmZvYnFqYWs4b3E4bGZraGczdDBxZ0Bn) - - 1. Triage issues and pull requests from the [No Status](#no-status) column (30 min) - 2. Discuss issues and pull requests from the [To discuss](#to-discuss) column (30 min) - -- Work meeting: [Mondays 13:00-15:00 CET](https://calendar.google.com/calendar/event?eid=NTM1MG1wNGJnOGpmOTZhYms3bTB1bnY5cWxfMjAyMjExMjFUMTIwMDAwWiBiOW81MmZvYnFqYWs4b3E4bGZraGczdDBxZ0Bn) - - 1. Code review on pull requests from [In review](#in-review). - 2. Other chores and tasks. - -Meeting notes are collected on a [collaborative scratchpad](https://pad.lassul.us/Cv7FpYx-Ri-4VjUykQOLAw), and published on Discourse under the [Nix category](https://discourse.nixos.org/c/dev/nix/50). - -## Project board protocol - -The team uses a [GitHub project board](https://github.com/orgs/NixOS/projects/19/views/1) for tracking its work. - -Items on the board progress through the following states: - -### No Status - -During the discussion meeting, the team triages new items. -To be considered, issues and pull requests must have a high-level description to provide the whole team with the necessary context at a glance. - -On every meeting, at least one item from each of the following categories is inspected: - -1. [critical](https://github.com/NixOS/nix/labels/critical) -2. [security](https://github.com/NixOS/nix/labels/security) -3. [regression](https://github.com/NixOS/nix/labels/regression) -4. [bug](https://github.com/NixOS/nix/issues?q=is%3Aopen+label%3Abug+sort%3Areactions-%2B1-desc) -5. [tests of existing functionality](https://github.com/NixOS/nix/issues?q=is%3Aopen+label%3Atests+-label%3Afeature+sort%3Areactions-%2B1-desc) - -- [oldest pull requests](https://github.com/NixOS/nix/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc) -- [most popular pull requests](https://github.com/NixOS/nix/pulls?q=is%3Apr+is%3Aopen+sort%3Areactions-%2B1-desc) -- [oldest issues](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc) -- [most popular issues](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc) - -Team members can also add pull requests or issues they would like the whole team to consider. -To ensure process quality and reliability, all non-trivial pull requests must be triaged before merging. - -If there is disagreement on the general idea behind an issue or pull request, it is moved to [To discuss](#to-discuss). -Otherwise, the issue or pull request in questions get the label [`idea approved`](https://github.com/NixOS/nix/labels/idea%20approved). -For issues this means that an implementation is welcome and will be prioritised for review. -For pull requests this means that: -- Unfinished work is encouraged to be continued. -- A reviewer is assigned to take responsibility for getting the pull request merged. - The item is moved to the [Assigned](#assigned) column. -- If needed, the team can decide to do a collarorative review. - Then the item is moved to the [In review](#in-review) column, and review session is scheduled. - -What constitutes a trivial pull request is up to maintainers' judgement. - -### To discuss - -Pull requests and issues that are deemed important and controversial are discussed by the team during discussion meetings. - -This may be where the merit of the change itself or the implementation strategy is contested by a team member. - -As a general guideline, the order of items is determined as follows: - -- Prioritise pull requests over issues - - Contributors who took the time to implement concrete change proposals should not wait indefinitely. - -- Prioritise fixing bugs and testing over documentation, improvements or new features - - The team values stability and accessibility higher than raw functionality. - -- Interleave issues and PRs - - This way issues without attempts at a solution get a chance to get addressed. - -### In review - -Pull requests in this column are reviewed together during work meetings. -This is both for spreading implementation knowledge and for establishing common values in code reviews. - -When the overall direction is agreed upon, even when further changes are required, the pull request is assigned to one team member. -If significant changes are requested or reviewers cannot come to a conclusion in reasonable time, the pull request is [marked as draft](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request#converting-a-pull-request-to-a-draft). - -### Assigned - -One team member is assigned to each of these pull requests. -They will communicate with the authors, and make the final approval once all remaining issues are addressed. - -If more substantive issues arise, the assignee can move the pull request back to [To discuss](#to-discuss) or [In review](#in-review) to involve the team again. - -### Flowchart - -The process is illustrated in the following diagram: - -```mermaid -flowchart TD - discuss[To discuss] - - review[To review] - - New --> |Disagreement on idea| discuss - New & discuss --> |Consensus on idea| review - - review --> |Consensus on implementation| Assigned - - Assigned --> |Implementation issues arise| review - Assigned --> |Remaining issues fixed| Merged -``` diff --git a/maintainers/backporting.md b/maintainers/backporting.md deleted file mode 100644 index 2424050c8..000000000 --- a/maintainers/backporting.md +++ /dev/null @@ -1,12 +0,0 @@ - -# Backporting - -To [automatically backport a pull request](https://github.com/NixOS/nix/blob/master/.github/workflows/backport.yml) to a release branch once it's merged, assign it a label of the form [`backport `](https://github.com/NixOS/nix/labels?q=backport). - -Since [GitHub Actions workflows will not trigger other workflows](https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow), checks on the automatic backport need to be triggered by another actor. -This is achieved by closing and reopening the backport pull request. - -This specifically affects the [`installer_test`] check. -Note that it only runs after the other tests, so it may take a while to appear. - -[`installer_test`]: https://github.com/NixOS/nix/blob/895dfc656a21f6252ddf48df0d1f215effa04ecb/.github/workflows/ci.yml#L70-L91 diff --git a/maintainers/release-process.md b/maintainers/release-process.md deleted file mode 100644 index f2b60d8e7..000000000 --- a/maintainers/release-process.md +++ /dev/null @@ -1,196 +0,0 @@ -# Nix release process - -## Release artifacts - -The release process is intended to create the following for each -release: - -* A Git tag - -* Binary tarballs in https://releases.nixos.org/?prefix=nix/ - -* Docker images - -* Closures in https://cache.nixos.org - -* (Optionally) Updated `fallback-paths.nix` in Nixpkgs - -* An updated manual on https://nixos.org/manual/nix/stable/ - -## Creating a new release from the `master` branch - -* Make sure that the [Hydra `master` jobset](https://hydra.nixos.org/jobset/nix/master) succeeds. - -* In a checkout of the Nix repo, make sure you're on `master` and run - `git pull`. - -* Compile the release notes by running - - ```console - $ git checkout -b release-notes - $ VERSION=X.YY ./maintainers/release-notes - ``` - - where `X.YY` is *without* the patch level, e.g. `2.12` rather than ~~`2.12.0`~~. - - A commit is created. - -* Proof-read / edit / rearrange the release notes if needed. Breaking changes - and highlights should go to the top. - -* Push. - - ```console - $ git push --set-upstream $REMOTE release-notes - ``` - -* Create a PR for `release-notes`. - -* Wait for the PR to be merged. - -* Create a branch for the release: - - ```console - $ git checkout master - $ git pull - $ git checkout -b $VERSION-maintenance - ``` - -* Mark the release as official: - - ```console - $ sed -e 's/officialRelease = false;/officialRelease = true;/' -i flake.nix - $ sed -e '/rl-next.md/ d' -i doc/manual/src/SUMMARY.md - ``` - - This removes the link to `rl-next.md` from the manual and sets - `officialRelease = true` in `flake.nix`. - -* Commit - -* Push the release branch: - - ```console - $ git push --set-upstream origin $VERSION-maintenance - ``` - -* Create a jobset for the release branch on Hydra as follows: - - * Go to the jobset of the previous release - (e.g. https://hydra.nixos.org/jobset/nix/maintenance-2.11). - - * Select `Actions -> Clone this jobset`. - - * Set identifier to `maintenance-$VERSION`. - - * Set description to `$VERSION release branch`. - - * Set flake URL to `github:NixOS/nix/$VERSION-maintenance`. - - * Hit `Create jobset`. - -* Wait for the new jobset to evaluate and build. If impatient, go to - the evaluation and select `Actions -> Bump builds to front of - queue`. - -* When the jobset evaluation has succeeded building, take note of the - evaluation ID (e.g. `1780832` in - `https://hydra.nixos.org/eval/1780832`). - -* Tag the release and upload the release artifacts to - [`releases.nixos.org`](https://releases.nixos.org/) and [Docker Hub](https://hub.docker.com/): - - ```console - $ IS_LATEST=1 ./maintainers/upload-release.pl - ``` - - Note: `IS_LATEST=1` causes the `latest-release` branch to be - force-updated. This is used by the `nixos.org` website to get the - [latest Nix manual](https://nixos.org/manual/nixpkgs/unstable/). - - TODO: This script requires the right AWS credentials. Document. - - TODO: This script currently requires a - `/home/eelco/Dev/nix-pristine`. - - TODO: trigger nixos.org netlify: https://docs.netlify.com/configure-builds/build-hooks/ - -* Prepare for the next point release by editing `.version` to - e.g. - - ```console - $ echo 2.12.1 > .version - $ git commit -a -m 'Bump version' - $ git push - ``` - - Commit and push this to the maintenance branch. - -* Bump the version of `master`: - - ```console - $ git checkout master - $ git pull - $ NEW_VERSION=2.13.0 - $ echo $NEW_VERSION > .version - $ git checkout -b bump-$NEW_VERSION - $ git commit -a -m 'Bump version' - $ git push --set-upstream origin bump-$NEW_VERSION - ``` - - Make a pull request and auto-merge it. - -* Create a milestone for the next release, move all unresolved issues - from the previous milestone, and close the previous milestone. Set - the date for the next milestone 6 weeks from now. - -* Create a backport label. - -* Post an [announcement on Discourse](https://discourse.nixos.org/c/announcements/8), including the contents of - `rl-$VERSION.md`. - -## Creating a point release - -* Checkout. - - ```console - $ git checkout XX.YY-maintenance - ``` - -* Determine the next patch version. - - ```console - $ export VERSION=XX.YY.ZZ - ``` - -* Update release notes. - - ```console - $ ./maintainers/release-notes - ``` - -* Push. - - ```console - $ git push - ``` - -* Wait for the desired evaluation of the maintenance jobset to finish - building. - -* Run - - ```console - $ IS_LATEST=1 ./maintainers/upload-release.pl - ``` - - Omit `IS_LATEST=1` when creating a point release that is not on the - most recent stable branch. This prevents `nixos.org` to going back - to an older release. - -* Bump the version number of the release branch as above (e.g. to - `2.12.2`). - -## Recovering from mistakes - -`upload-release.pl` should be idempotent. For instance a wrong `IS_LATEST` value can be fixed that way, by running the script on the actual latest release.