<ekleog>
I'd vote for using the same tooling as the one being developed for https://github.com/NixOS/rfcs/pull/34 , as it's being designed exactly for this, but maybe it's too “long-term” and a bot to mark commits as “reviewed” would do it too?
<ekleog>
(though if we start reviewing NUR… why not integrate with nixpkgs straight away? unless the issue is one with nixpkgs' license?)
<Mic92>
It would be not the same level of review we do for nixpkgs.
<Mic92>
Also we want to allow more experiements in NUR.
<Mic92>
Like opionated patches, large package sets and old version of packages.
<ekleog>
hmm yeah ok :)
<Mic92>
The reviewed channel would be also an alternative way of fetching NUR. The default channel would be still unreviewed and non-blocking.
<Mic92>
ekleog: if this tool gets ever implemented, I will consider using it. Otherwise I will extend our current travis with a custom job, which is not hard to do.
<Mic92>
This needs to be done anyway so the tooling developed in this rfc would be orthogonal
<ekleog>
oh indeed, I was thinking about the issues of writing an irc bot to transmit information to the thing that bumps the channel, if there's an easy way it's all good :)
<ekleog>
nice :) I clearly don't know enough about travis, only know the existence of .travis.yml and to send random stuff at it until it does what I want
<Mic92>
In the long term I probably have to replace the current travis setup by something that output per repository
<Mic92>
So repository owners are notified if they break something.
<ekleog>
yeah, that's the point of #34 (trying to do it in a way so that it can even be eventually enforced automatically :) see https://github.com/git-wotr/spec/ , most of the talk being in issues currently)
<ekleog>
issue is, forcing people to “just create a key now” doesn't work out from a security point of view :/
<ekleog>
like, if the key ends up live on a system running ff53, it'll likely cause more harm than good