Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC 0027] Trusted bots #27

Closed
wants to merge 6 commits into from

Conversation

matthewbauer
Copy link
Member

WIP, looking for comments and co-authors.

Rendered


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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As an illustration of the heavy weight of such an approach I can say that ofborg cannot be fully Nix-built right now.

@jgeerds
Copy link
Member

jgeerds commented Mar 28, 2018

Am I the only one who dislike bots whose name contain other usernames like @GrahamCOfBorg? Don't get me wrong - I really appreciate the work done by @grahamc. It's such a massive improvement for us!

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)

@7c6f434c
Copy link
Member

@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 @GrahamCOfBorg it seems like the least of concerns.

@Profpatsch
Copy link
Member

@jgeerds The project is called ofborg and the specific instance is called @grahamcOfBorg, because @grahamc manages and maintains it. Pretty straightforward.

@zimbatm
Copy link
Member

zimbatm commented Mar 30, 2018

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.

@Nadrieril
Copy link
Member

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.

@7c6f434c
Copy link
Member

@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.

@Nadrieril
Copy link
Member

Nadrieril commented Jul 12, 2018

@7c6f434c Oh thanks, I was indeed confused. My comment does still apply to @zimbatm's point though.

@domenkozar
Copy link
Member

@matthewbauer says I would call it abandoned for now... I think there could be a use for it at some point, but right now I think it makes sense to use nixpkgs-update for everything.

@domenkozar domenkozar closed this Jan 22, 2019
infinisil referenced this pull request in nixpkgs-architecture/rfc-140 Jan 30, 2023
Allow variants in all-packages to use unit directories
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants