[RFC 0027] Trusted bots #27
Conversation
|
|
||
| Why do we need bots? Nix has never had the accessibility of a package manager like Homebrew or the massive user base of a distro like Debian. To compete with them, we need to make our developers more productive. Bots can be a massive help. | ||
|
|
||
| Currently running bots: |
There was a problem hiding this comment.
What even is a bot? As far as I understand, Vulnix might not be strictly a bot — it seems to produce Markdown that is then published. And there are multiple package generators (* to Nix) that have the same mode of operation — generate content for a human to review and push.
On the other hand, https://monitor.nixos.org/ never did anything with the GitHub issues, but was constantly running, polling external source of information and providing its own web interface. Was it a bot?
| - Travis CI bot | ||
| - [mention-bot](https://github.com/facebook/mention-bot) | ||
|
|
||
| Right now we have kind of a wild west of bots where anyone can create and manage their own bots. This is great for iterating on new ideas, but has certain dangers. The biggest danger is that these maintainers get hit by a bus and are unable to continue managing the bot. In the long-term, my goal is to have these bots managed by the NixOS organization. The trusted bots program is the first step in that direction. |
There was a problem hiding this comment.
Re: wild west: I think this sets a slightly wrong tone. Is it wild west that we use different editors? With some private keybindings to accelearte common Nix editor tasks? With some wrapper scripts to help do routine nix-related tasks?
Bots requiring special access (more than an external user) are a separate topic, but the only bot that has special non-human-gated access right now has got a separate account and member status, so not exactly wild west.
Maybe the framing should be «deployment best practices and a process for recognition the bots, directly or indirectly used by many Nixpkgs developers, that have become a valuable community resource»? Maybe with «attracting maintenance help» angle of putting the repositories under the organisation umbrella, maybe with a process of infrastructure management by NixOS Foundation for the most critical tools (or tools needing to run autonomously) — that part needs feedback from people managing Foundation, of course.
Re: bus: let's be honest and notice that the largest risk for a bot — and also the largest risk for a package! — is that the author becomes too busy with other things and has no time to maintain it.
| - [ ] Create a "bots" team in the NixOS org. | ||
|
|
||
| ## Requirements for trusted bots | ||
| - A bot must run on a designated GitHub user. Name preferably ending in "OfBorg" (as in @GrahamCOfBorg) or just including "bot". Profile homepage should link to software repo. Once accepted, bots will be added to a "bots" team on GitHub (can be used to filter them out with "-team:NixOS/bots", see NixOS/nixpkgs#37181). |
There was a problem hiding this comment.
ofborg is the repository name of the specific bot, so it wouldn't be a good naming pattern. If we have a team of bots, naming convention shouldn't be important…
Also, filtering needs a separate chatty-bots team: decreasing visibiltiy of Vulnerability Roundups is a bad idea.
Also, I think the end-goal for some bots is to get their own UI and stop saying anything in the GitHub issues…
| - A bot must run on a designated GitHub user. Name preferably ending in "OfBorg" (as in @GrahamCOfBorg) or just including "bot". Profile homepage should link to software repo. Once accepted, bots will be added to a "bots" team on GitHub (can be used to filter them out with "-team:NixOS/bots", see NixOS/nixpkgs#37181). | ||
| - Maintainer should be designated who maintains and runs bot. Some sort of contact information or a designated mailing list would make sense to have. | ||
| - Bot software should have its own public GitHub repo. If possible, software should be listed in Nixpkgs. | ||
| - A reproducible service must be available as either a NixOS module or just a "configuration.nix" file in the repo. The bot can be run on any hardware but the eventual goal is to run this on NixOS foundation hardware or through Graham's OfBorg. |
There was a problem hiding this comment.
@grahamc do you think making ofborg a bot platform is a good idea?
(or should ofborg be eventually Foundation-run…)
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| This process could formalize things too much. We want to allow people to iterate quickly on their bots. Also it's unclear how many bots we will have in the future, but hopefully this RFC will encourage more development in this area. |
There was a problem hiding this comment.
As an illustration of the heavy weight of such an approach I can say that ofborg cannot be fully Nix-built right now.
|
Am I the only one who dislike bots whose name contain other usernames like It's just that I think that it may confuse new contributors and it looks a bit… I don't know… "disorganised" ? (from a "Corporate identity" point-of-view) |
|
@jgeerds I think projecting a consistent corporate identity should not be higher priority than having consistency. If a bot runs under control of NixOS Foundation and at least three people (note: that's more than the apparent number of project members who can reboot Hydra servers) can merge and deploy updates, there can be a question whether tying the bot identity to the lead developer identity is misleading. Right now even for |
|
The RFC seems to be addressing a subset of a larger problem which is infrastructure control. We currently have a number of services running on different machines and it's not always clear who to ping when there is a problem. It would be nice to have a hardware team that is responsible for all of this. |
|
I'd say that having decent documentation of what bots/services are running where and who is in charge of each of them would already go a long way towards making this whole thing manageable, without necessarily needing a dedicated team. |
|
@Nadrieril note that the team in the text of the RFC is actually not a human dedicated team, it is a team of bots, so a kind of executable (i.e. usable in filters) documentation. |
|
@matthewbauer says |
Allow variants in all-packages to use unit directories
WIP, looking for comments and co-authors.
Rendered