See https://github.com/NixOS/nixpkgs/issues/437208#issuecomment-3288623669
Depends on https://github.com/NixOS/org/pull/172
As documented below, the idea is to essentially group all changes
rebuilding all VM tests with kernel updates and merge them together into
`master` whenever the Linux kernels get updated.
This documents the workflow of updates in the nixpkgs manual. While at
it, I removed the README from the packages because
* it's horribly outdated
* I didn't even know it exists which confirms that its discoverability
was very poor
and added the relevant portions into the nixpkgs manual as well.
While squash-merges have been discouraged from already, they become
impossible to do when the Merge Queue is enabled. In certain scenarios
it was tolerated to use these, however, thus we introduce an acceptable
replacement instead.
By making explicit that pushing to contributors PRs is allowed by
default, it should be easier for committers to do so.
This serves as an overview of the process as we currently live it and as a guide
for getting it done quickly and efficiently for people who haven't been
contributing to Nixpkgs for many years.
The intention is to document how the process currently works, set expectations
right, provide recommendations on getting through the process and motivate
people to help us committers help them better. Win-win for everyone.
Co-authored-by: Valentin Gagarin <valentin@fricklerhandwerk.de>
Co-authored-by: Leona Maroni <dev@leona.is>
We sometimes have reviews that are blocked because of miscommunication between author
and reviewer, we make this clear so that reviewers and authors can refer to a block of
"authoritative" text to unblock their own situations.
Co-authored-by: Valentin Gagarin <valentin@gagarin.work>
The graph right above the table has the order as `master` ⇒ `staging-next` ⇒ `staging`.
This corresponds with the workflow, i.e. automatic merges happen in that direction and the manual merging is in reverse direction of that.
As a first time reader of this document the table was very confusing due to the disparity of that.
With this change the table should read more fluently for people not familiar with the workflow since the table follows the step-by-step flow of commits.
Signed-off-by: benaryorg <binary@benary.org>
The fact that sandboxing is already enabled by default is mentioned in
the pull request template. Hence, it might be confusing to ask to enable
sandboxing in CONTRIBUTING.md.
Also follow the `one sentence per line` guideline.
Co-authored-by: Silvan Mosberger <github@infinisil.com>
GitHub supported special markdown syntax for emphasising blocks for some
time. This was however a beta feature, and still is, so it's subject to
changes.
Recently such a change happened: The syntax is different now.
See https://github.com/orgs/community/discussions/16925 for more
information
