This introduces the `pkgs/by-name` directory as proposed by RFC 140.
Included are:
- The implementation to add packages defined in that directory to the
top-level package scope
- Contributer documentation on how to add packages to it
- A GitHub Actions workflow to check the structure of it on all PRs
I want to take ownership of this part of the documentation, especially
with the cleanup in https://github.com/NixOS/nixpkgs/pull/245243. Doing so
before that PR is merged also allows me to get notified about any potential
future merge conflicts before they happen.
It is hard to get people to test changes to our kernel expression on
anything other than x86_64 and aarch64 before merging changes.
Therefore, I would like to be notified of PRs opened agains this
file, so that I can hopefully catch breakage before it is merged,
rather than afterwards.
I don't claim ownership of anything, but I would like to be notified
of PRs opened against the following paths where I've put a lot of
work into cleanup and deduplication:
lib/systems
pkgs/stdenv
pkgs/build-support/cc-wrapper
pkgs/development/compilers/gcc
Apparently CODEOWNERS is how you tell github you want to be notified
of such things.
I do a lot of work on QEMU VM and make-disk-image and I was bitten by an
unnotified change recently, so I want to chime in the future changes of
this file.
We currently have 5800 python modules in that path, and we're seeing
roughly 1000 pull requests for these modules per month.
Having @FRidh and @jonringer requested on every PR that touches a
python package isn't helping anyone, nor is it sustainable for any one
person to have that number of incoming notifications.
I think it's time to get rid of that code ownership.
Adds initial work towards a `lib.path` library
Originally proposed in https://github.com/NixOS/nixpkgs/pull/200718, but has
since gone through some revisions
Co-Authored-By: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-Authored-By: Robert Hensing <robert@roberthensing.nl>
glib expression is messy enough as is.
Also rename the `glib-schema-to-var` argument to `schemaIdToVariableMapping` to better match Nixpkgs coding style.
the number of pull requests against documentation is too high to handle
on the side, and getting assigned as reviewer for all of them sends the
wrong message to authors.
See https://github.com/Gabriel439:
Hi, there! 👋🏼
I renamed my GitHub account from @Gabriel439 to @Gabriella439, so if you got here from an old profile link you can visit my new profile here:
@Gabriella439
I created this placeholder account so that:
… people who visit old links to my profile can find my new profile
… other people cannot impersonate my old handle
… GitHub continues to redirect old links to my repositories indefinitely
With the re-implementation in Python merged[1], it no longer makes sense
for me to track issues and pull requests. I did this originally because
people were forgetting (rightfully so) to run tests against all that
proprietary stuff we have in nixpkgs that is using autoPatchelfHook.
We still can't test these automatically but with me no longer being the
author of the code, I hereby drop my entry in CODEOWNERS and instead
replace it with layus, who's the author of the rewrite.
[1]: https://github.com/NixOS/nixpkgs/pull/149731
Signed-off-by: aszlig <aszlig@nix.build>
I currently do not have much time to work on nixpkgs. Remove
myself as a maintainer from a bunch of packages to avoid that
people are waiting on me for a review.
I am maintaining out-of-tree PHP expressions (https://github.com/fossar/nix-phps)
so I would like to get notified of changes of the code I depend on,
even though I cannot commit to becoming a PHP maintaintainer at the moment.
CODEOWNERS files always take that *last* match for a specific match.
Having two lines for the same path will only ever result in the last
line being used. The intention here was that both of these individuals
are owners of the neovim space and not just one.
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.
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.
