Remove elements of the PR template that have a low signal/noise ratio,
and add one that I think would have a good signal/noise ratio.
-----
Remove:
Determined the impact on package closure size (by running `nix path-info
-S` before and after)
-----
Rationale:
This is rarely done in practice, and apart from for specific packages
this is usually not a good indicator of anything useful
It might make sense to re-introduce it with two holes to fill, but then
we would have to make a serious decision to never land without these two
numbers filled in or with too big a regression, because in practice this
box has been a no-op in many cases.
Maybe just integrating this check in nixpkgs-review would bring the most
benefit here?
-----
-----
Remove:
Ensured that relevant documentation is up to date
-----
Rationale:
This is fuzzy, “relevant documentation” is way too often hard to find
-----
-----
Add:
Added a release notes entry if the change is major or breaking
-----
Rationale:
This is way too often forgotten, and is also a self-contained easy task
-----
If I receive the mail notification that staging(-next) merge failed,
I either need to check `git log staging-next` or click the action run link
to find out where should I resolve the conflict.
To save time, let’s include the information about which step failed right in the comment.
release-haskell.nix is intended to be a replacement for
https://github.com/peti/ci/blob/master/haskell-nixpkgs.nix
which is currently the main expression for the haskell-updates jobset
on hydra (in the nixpkgs project).
It has the same jobs as the old haskell-nixpkgs.nix file:
* haskellPackages.*
* haskell.compiler.*
* Some extra haskell packages for certain compilers
The following jobs are new:
* tests.haskell.*
* A manually maintained list of top-level haskell packages (most of them
using justStaticExecutables)
* An aggregate job which is intended to aid merging the haskell-updates
branch: It holds an arbitrary list of haskell-related packages and
tests we intend have working at all times. This is still somewhat
incomplete and should be extendend in the future.
Additionally a lot of refactoring has been done and some unnecessary
code has been eliminated. Due to the increased set of jobs and my
ideas of convenience however, the code size has grown overall.
I've tried document the individual parts and would be happy about
feedback in general.
One future improvement could be making adding top-level haskell packages
more convenient and adding them all to the aggregate job automatically.
It's been at least a year since I kept up to date with Ruby, and I
don't think I really have anything left to offer Nixpkgs in terms of
Ruby expertise.
- Error if the commenter doesn't have write access or maintainers can't edit the PR branch.
- Close and comment on PR after rebase so that actions are run when it's reopened.
This doesn't happen currently as we're using the default github token which isn't allowed to trigger other actions.
- Disallow unwanted rebases.
e.g. invalid branches, redundant rebases or rebasing permanent branches onto permanent branches.
I really hate the very concept of this file (the reason being that I
think "owner" implies some form of BDFL rather than just being
notified), but since there were recent[1] changes[2] in auto-patchelf.sh
which I missed it's probably a good idea to add myself there solely for
being notified, because ofborg can't seem to infer maintainer
information here.
To make indentation consistent with all the other entries in the
codeowners file, I also re-indented the other entries in the "Nixpkgs
Internals" block.
[1]: https://github.com/NixOS/nixpkgs/pull/101142
[2]: https://github.com/NixOS/nixpkgs/pull/106830
Signed-off-by: aszlig <aszlig@nix.build>
Automate the merging of `master` -> `staging-next` -> `staging`.
Our main development branch is `master`. Large rebuilds go to `staging`.
Periodically, `staging` is merged into `staging-next` for stabilization.
When considered sufficiently stable, `staging-next` is merged into
`master`.
As changes arrive on these branches, it is important that they're all
updated regularly with eachothers changes. This commit automates that
part.
moves all the information to the Markdown document that we can
dynamically update and tries to make things more concise and scannable.
Co-authored-by: Ryan Mulligan <ryan@ryantm.com>
Co-authored-by: Travis A. Everett <travis.a.everett@gmail.com>
In case ofborg is down this will not mark the CI as green.
Also if other github actions are used and pass
checks will be still marked as pending even if other other github
actions have passed.
As somewhat discussed at: https://git.io/JJkRa, make the bot's message a
bit more instructive, and clearer as for what it will and won't do, so
random contributors will have a better idea what this is about.
Also: Split stale issues' and PRs' messages because each should
suggest different actions to do.
Before this, the message being written is:
```
Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:
1. Search for maintainers and people that previously touched the
related code and @ mention them in a comment.
2. Ask on the [NixOS Discourse](https://discourse.nixos.org/). 3. Ask on the [#nixos channel](irc://irc.freenode.net/#nixos) on
[irc.freenode.net](https://freenode.net).
```
Co-authored-by: zowoq <59103226+zowoq@users.noreply.github.com>
.github/stale.yml: fix newlines
The text is quite long and hard to read in hub (because it is one whole line
with no line breaks). Also simplified the language/sentence structure a bit for
non-native speakers.
This is really essential thing that everyone should be doing.
A few extra notifications won't hurt anyone, and we should be tracking issues
to connect them to the best people who can handle them.
Co-Authored-By: Cole Helbling <cole.e.helbling@outlook.com>
