pyrox.dev
maintainers/README: add guidelines for committers (#351744)
authored by
+51
maintainers/README.md
+51
maintainers/README.md
···
175
175
176
176
# nixpkgs-merge-bot
177
177
To streamline autoupdates, leverage the nixpkgs-merge-bot by commenting `@NixOS/nixpkgs-merge-bot merge` if the package resides in pkgs-by-name and the commenter is among the package maintainers. The bot ensures that all ofborg checks, except for darwin, are successfully completed before merging the pull request. Should the checks still be underway, the bot patiently waits for ofborg to finish before attempting the merge again.
178
+
179
+
# Guidelines for Committers
180
+
181
+
When merging pull requests, care must be taken to reduce impact to the `master`
182
+
branch. If a commit breaks evaluation, it will affect Ofborg evaluation results
183
+
in other pull requests and block Hydra CI, thus introducing chaos to our
184
+
workflow.
185
+
186
+
One approach to avoid merging such problematic changes is to wait for
187
+
successful Ofborg evaluation. Additionally, using tools like
188
+
[nixpkgs-review](https://github.com/Mic92/nixpkgs-review) can help spot issues
189
+
early, before Ofborg finishes evaluation.
190
+
191
+
## Breaking changes
192
+
193
+
In general breaking changes to `master` and `staging` branches are permitted,
194
+
as long as they are documented in the release notes. Though restrictions might
195
+
apply towards the end of a NixOS release cycle, due to our feature freeze
196
+
mechanism. This is to avoid large-scale breakages shortly before and during
197
+
a Zero Hydra Failures (ZHF) campaign. These restrictions also intend to
198
+
decrease the likelihood of a delayed NixOS release. The feature freeze period
199
+
is documented in the announcement of each release schedule.
200
+
201
+
> These are some example changes and if they are considered a breaking change
202
+
> during a freeze period:
203
+
>
204
+
> - `foo: 1.2.3 -> 1.2.4` - Assuming this package follows semantic versioning
205
+
> and none of its dependent packages fail to build because of this change, it
206
+
> can be safely merged. Otherwise, if it can be confirmed that there is no
207
+
> major change in its functionality or API, but only adding new features or
208
+
> fixing bugs, it
209
+
> can also be merged.
210
+
> - `unmaintained-software: drop` - If this PR removes a leaf package or the
211
+
> removal doesn't otherwise break other packages, it can be merged.
212
+
> - `cool-tool: rename from fancy-tool` - As long as this PR replaces all
213
+
> references to the old attribute name with the new name and adds an alias,
214
+
> it can be merged.
215
+
> - `libpopular: 4.3.2 -> 5.0.0` - If this PR would trigger many rebuilds
216
+
> and/or target `staging`, it should probably be delayed until after the
217
+
> freeze-period is over. Alternatively, if this PR is for a popular package
218
+
> and doesn't cause many rebuilds, it should also be delayed to reduce risk
219
+
> of breakage. If a PR includes important changes, such as security fixes, it
220
+
> should be brought up to
221
+
> release managers.
222
+
> - `nixos/transmission: refactor` - If this PR adjusts the type, default value
223
+
> or effect of options in the NixOS module, so that users must rewrite their
224
+
> configuration to keep the current behavior unchanged, it should not be
225
+
> merged, as we don't have enough time to collect user feedback and avoid
226
+
> possible breakage. However, it should be accepted if the current behavior
227
+
> is
228
+
> considered broken and is fixed by the PR.