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.
There have been a couple of instances where I have by chance noticed PRs
which add non-free licenses without them being appropriately marked. I'd
like to be notified of proposed changes to licenses to make it less
likely that this sort of thing slips by.
I'm happy to keep helping out with Haskell infrastructure where I can,
but I don't have a good system for handling the accidental codeowner
pings caused by target branch switches.
Since the development of #38698, I have been radically overhauling the
PostgreSQL support and plan on maintaining it in the long run, taking
over from @ocharles, who authored most of it initially.
However, while #38698 has not been merged (yet), I'm taking the time to
go ahead and add myself as the owner of all the related code, so that I
can be marked as a reviewer for things people submit in the mean time.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
I’d like to be notified of changes so I can ensure the API always follows the same patterns.
Later (more specific) files replace more general codeowners [according to the documentation](https://help.github.com/articles/about-codeowners/), so I also listed `edolstra` and `nbp` again.
This format uses the path matching algorithm as the .gitignore format.
The paths need to be prefixed with a / to become absolute, otherwise it
will match all of these files.
The paths will also match any of the sub-paths by default so it's not
necessary to use the `*` like in bash globbing.
This sets up the Darwin-maintainers team as CODEOWNERS for Darwin paths. So anyone in that team will get notified (instead of just listing individuals).
/cc @org/darwin-maintainers
Some time ago GitHub introduced the CODEOWNERS file. The file is similar
to the MAINTAINERS file that was proposed in
https://github.com/NixOS/nixpkgs/issues/13602. Code owners will
automatically receive a review request.
