Nominate @agilesteel

[philiptaron]

I'm nominating @agilesteel for a Nixpkgs commit bit after seeing that he accidentally opened a request to join the committers team.

Vladyslav has maintained the Scala/JVM developer toolchain in Nixpkgs since 2022: first by steadily bumping bloop through two major versions and adding aarch64-darwin support, then by taking ownership of the whole cluster. He now maintains bloop, sbt, metals, mill, scala-cli, scalafmt, coursier, ammonite, giter8, liquibase and herdr.

In August 2026 he audited every Scala tool in his scala-seed flake and opened nine separate cleanup PRs, one per tool. They fixed real, long-hidden defects: an installCheckPhase that never ran, jre overrides that ambient JAVA_HOME silently defeated, a preferLocal typo, and update scripts that would have proposed milestone builds. He also noticed that Liquibase had relicensed to FSL-1.1 while Nixpkgs still advertised Apache-2.0 (#554516). That work was AI-assisted and disclosed in full under the automation policy: Assisted-by: trailers on every commit and separate disclosure on every PR summary and review.

• sbt: 1.12.13 -> 2.0.6 (#552788)
• liquibase: fix license (#554516)
• ammonite: fix jre handling (#552781)
• mill: 1.1.7 -> 1.1.8 (#552787)
• Review of graalvm-ce (#553693): hash verification, release-train change, untested consumers, then deferred to the domain maintainers

46 of his 52 merged PRs were merged by one committer (@kubukoz). His review record is small (6 reviews outside r-ryantm bumps, 3 of them substantive), so this nomination rests on quality and tenure rather than volume.

---

	#	# excluding @r-ryantm
PRs authored	52	N/A
PRs authored & merged	52	N/A
PRs reviewed	29	6
PRs otherwise commented	8	5
PRs otherwise involved	6	1
Issues authored	0	N/A
Issues otherwise commented	0	N/A

^{Generated with https://gist.github.com/pbsds/7af827a53c103cd3d40902f9b0b21843.}

[philiptaron]

@agilesteel, I opened this on your behalf from seeing that you had requested a commit bit in the team page on GitHub.

I'd definitely like to see more review feedback. Could you also please respond to this PR with what you intend to do if given the commit bit? Please review #130.

Do note that I have rejected that request to join the team; this PR is the process.

[agilesteel]

Thank you @philiptaron

Honestly my biggest reason to get it was so that I could merge bot PRs that simply bump versions. So far the only way to do so was to become a maintainer which ended up nudging me towards truly maintaining some of the packages. Most of the time I'm seeing trivial bump PRs laying around for weeks unmerged.

[agilesteel]

Here is another reason. Dopple CLI had a release 6 days ago https://github.com/DopplerHQ/cli/releases/tag/3.76.6. The bot hasn't opened a PR yet. I could open it myself, it's a one liner afterall, but opening it myself has an even smaller chance of it being merged. If I was a maintainer of this package I would at least be able to wait for the bot to open up the PR and then I could ping the bot to merge it for me. I can't do this for my own PRs. In fact I can't even do it for the packages that I do maintain. I once waited for 10 days for the bot to open the PR because of this.

Is there another mechanism that I'm missing? Maybe the commit bit is too big of a hammer for what I need?

Here is another example: not even my PR NixOS/nixpkgs#567056 I am a maintainer of the package. I review it, tested locally, approved it, but I can't merge it.

PS

Of course if it was something super urgent like a security fix I could always find ways via overlays or forking but it shouldn't be necessary. What am I missing?

[kubukoz]

I can vouch for @agilesteel, based on personally knowing him and all these PRs :)

[herbetom]

Just some quick thoughts about getting stuff merged. Although not sure how appropriate they are in this PR. Please mark it as off topic otherwise.

If you're an maintainer for a package there will be an automatic label on that PR "11.by: package-maintainer". Stuff like that gives confidence towards an PR. So does linking the Release Notes. And if it's for example quite a minor code change you can show a reviewer that there isn't much to worry about by linking a diff.
What is sensible depends on the package and PR in question.

Also searching for co-maintainers seems like a generally good idea. If you open a PR and another maintainer of that package approves it it's probably merged more quickly (although i don't have stats for that claim). But that's of course more easily said then done.

You can also look into the update mechanism r-ryantm uses to find new versions for a particular package. In the worst case it might be based on repology data. That means other distros need to pick up a new version, ship it and only then the bot has the chance to see that it should try to do an update. https://nix-community.github.io/nixpkgs-update/nixpkgs-maintainer-faq/#no-update An updateScript could possibly help here to speed that up.

Regarding security fixes: There is the "1.severity: security" label you can apply if something addresses some security aspect (it's red and highlights the PR somewhat) and then there also are two Matrix Rooms focused on Security: https://nixos.org/community/teams/security/
I personally wouldn't use them for every minor security fix these days but if it's something relevant, and you mention it there, that usually does speed things up.