Team request - NixOS/browser-maintainers

[JohnRTitor]

Nixpkgs have a quite a LOT of browsers compared to other distros' official repos.

However as things stand, Nixpkgs is currently suffering from huge PR burden (7000+) as of now. This means if a package doesn't have an active commiter as one of its maintainer, getting an update merged could take forever. This leads to situations like #413020.

This is highly undesirable as browsers are security critical packages. So much so that each update is expected to be merged in a timely manner and backported to each supported NixOS release.

Obviously we can just get rid of the unmaintained browsers, but that isn't a good solution without upsetting its existing users.

Problems

• Browsers are not being updated in a timely manner
• Even if an update PR is made, getting it merged can take a lot of time

Proposed solutions

1. add a meta.attribute, ie. meta.securityCritical = true, packages with this attribute will be prioritised and updated more often by @r-ryantm. A proposed script run interval is 24 hours.
2. we create a commiter only team called @NixOS/browser-maintainers, their job would be to quickly evaluate and merge browser updates.

Notes

• It is understandable that not everyone in the team will be in possession of a builder that can build browsers in a reasonable amount of time. Nix Community builders can be utilised for this purpose.
• Most browsers on Nixpkgs are fetched from a binary release (except Chromium, Firefox, and Firefox forks) so building them locally wouldn't be an issue.
• Not every browsers on Nixpkgs need to be under this teams wing, if maintainers of a particular browser are confident that they can manage on their own, they should be allowed to work independently.
• Purpose of this team is NOT to interfere with the judgement of existing maintainers, but to merge updates in a timely manner.
• For fulfilling the purpose of the team, only contributors with write access may be added to this team.

Expectations from its members

• MERGE update PRs as soon as possible if pinged
• BACKPORT updates to supported stable releases (ie, 24.11, 25.05 as of this issue creation)
• DO NOT interfere with the judgement of existing maintainers unless it is security related

---

CCing existing browser maintainers for feedback:

• Chromium - @networkException @emilylange
• Chrome - @JohnRTitor @jnsgruk
• Firefox - @mweinelt
• Tor Browser - @felschr @panicgh @joachifm @hax404
• Librewolf - @squalus @DominicWrege @fpletz @LordGrimmauld
• Librewolf-bin - @DominicWrege
• Brave - @uskudnik @rht @JeffLabonte @nasirhm @buckley310 @matteopacini
• Vivaldi - @marcusramberg @max06 @wineee
• Mullvad browser - @felschr @panicgh @SigmaSquadron
• Ladybird - @fgaz

Additionally CC @infinisil @K900 @drupol @GaetanLepage @winterqt @vcunat @emilazy @NixOS/security

Please note that this list is not exhaustive, some of the browsers may have been missed. Feel free to list them below.

[mweinelt]

I have no capacity to deal with additional browsers on top of my normal workload.

[JohnRTitor]

Noted. I should clarify that technically any commiter who intend to volunteer can be added to the team, so they receive notifications on browser update PRs. It's not mandatory that those who are invited to this discussion have to be in the new team.

[Daholli]

Since I was the one that reinitialized edge recently since i need it for a side project, i very much agree that it would be nice to have either something that can detect pure version bumps and allow us to merge it via the merge bot, or some other way to keep these packages up to date while burdening the commit bit holders the least.

Is the Idea of parsing git diffs for the merge bot something that would be allowed generally? I am willing to look into it if there is at least some interest there.

[max06]

One could probably use an LLM for that... (I'll show myself out!)

I think the important part is checking if there's a change at all. That should be automated, and imho more often than just every 24 hours. I mean, if a publisher distributes directly there's basically no additional waiting time between the update announcement and the user getting the new version installed in background. If we compare this to nixpkgs... update published -> branch/PR created -> tests running -> approval -> channel propagation and backports -> lazy users running their updates less than once a week... Okay, we can't influence the last point there, but we should reduce the times required for the other steps as much as possible. Automation is the logical consequence.

I'm no nix-expert, or an experienced nixpkgs-maintainer or so. I can't tell how easy or complicated it would be to unify the various browser packages enough to get automation in place. But I'd probably separate chromium-based browsers from firefox-variants and treat them separately in the first place. Maybe additionally split them into open-source (or compiled from source) vs repackaged binaries. The other option would be what @Daholli suggested: Version bump automation, but not limited to browsers only. Maybe combined with an opt-in flag and smoke-tests in the package. A bot could detect such a bump, run the build and tests and auto-merge if no issues observed. I'd probably add some semver parsing and limit automated merges to minor/patchlevel changes.

Basically similar to renovate with proper rules.

// I'm also fine merging a PR with a version bump on any browser if I'm the first reacting!

[fgaz]

Ladybird is in alpha, has no releases, and uses the unstable git updater. Updating it every 24 hours would be way too much

[fgaz]

Minor engines other than ladybird:

• Netsurf - Recently dropped by @AndersonTorres (unfortunate! this is the most established of this list. maybe I'll pick it up)
• Surf - @joachifm
• Litebrowser - @fgaz
• Dillo - Recently dropped by @AndersonTorres
• Dillo Plus - @fgaz
• Servo - @mweinelt @supinie
• Text mode web browsers?

[LordGrimmauld]

We also have webkitgtk, which is what powers gnome-web, for example. That wasn't listed here at all.
(admittedly i don't see gnome-web packaged, but we do have the engine...)

[vcunat]

Maybe some people will want to be in this team, but I find it weird to promise to maintain arbitrary browsers that someone else decides to add in.

[wolfgangwalther]

Please note that this list is not exhaustive, some of the browsers may have been missed.

Related: https://github.com/NixOS/nixpkgs/pull/404408/files

[wolfgangwalther]

add a meta.attribute, ie. meta.securityCritical = true, packages with this attribute will be prioritised and updated more often by @r-ryantm. A proposed script run interval is 24 hours.

Would something like this potentially enable non-committer maintainer teams for browsers? (independently of a generic "browsers-maintainers" team)

Instead of more frequent intervals, it could also just be a way to manually trigger r-ryantm for a specific package immediately.

[JohnRTitor]

Initial proposal of mine was to create a commiter only team, so we can merge browser updates (from r-ryantm or other maintainers) quickly.

Would something like this potentially enable non-committer maintainer teams for browsers?

That's a valid question, suppose we allow non-commiters (ie, members of nixpkgs-maintainers team) in @NixOS/browser-maintainers.
They would need to utilise the merge bot (@NixOS/nixpkgs-merge-bot) to merge PRs against the paths as specified in:

nixpkgs/.github/labeler-no-sync.yml

Lines 37 to 64 in a01f07f

	# Browser updates should always be backported.
	- pkgs/applications/kde/angelfish.nix
	- pkgs/applications/kde/falkon.nix
	- pkgs/applications/kde/konqueror.nix
	- pkgs/applications/networking/browsers/**/*
	- pkgs/by-name/br/brave/**/*
	# Added in December 2024, uncomment for 25.05
	# - pkgs/by-name/ca/catalyst-browser/**/*
	- pkgs/by-name/ch/chawan/**/*
	- pkgs/by-name/di/dillo-plus/**/*
	- pkgs/by-name/di/dillo/**/*
	- pkgs/by-name/ed/edbrowse/**/*
	- pkgs/by-name/ep/epiphany/**/*
	- pkgs/by-name/go/google-chrome/**/*
	- pkgs/by-name/ly/lynx/**/*
	- pkgs/by-name/mi/microsoft-edge/**/*
	- pkgs/by-name/mi/midori-unwrapped/**/*
	- pkgs/by-name/mu/mullvad-browser/**/*
	- pkgs/by-name/op/opera/**/*
	- pkgs/by-name/to/tor-browser/**/*
	- pkgs/by-name/vi/vimb-unwrapped/**/*
	- pkgs/by-name/w3/w3m/**/*
	- pkgs/desktops/lomiri/applications/morph-browser/**/*
	- pkgs/development/libraries/webkitgtk/**/*
	- pkgs/kde/gear/angelfish/**/*
	- pkgs/kde/gear/falkon/**/*
	- pkgs/kde/gear/konqueror/**/*

This would require changes in the merge bot (CC @Lassulus @Mic92), and will require a lot of community trust on those non commiter team members. Commiters in Nixpkgs are selected using a process (NixOS/nixpkgs-committers#50) and are trusted by their peers.

I am not sure if this is something we want to do right now.