We have 2 solution, either we stop the regressions when a pull request (PR) is made, or we stop it when the fire is in. The fireman role is hard to keep, and we should be verifying as much as possible at the PR time. Also, if we want to avoid firemans, we probably want to forbid pushing patches to the repository without having made a pull request at first. Which means, no more massive updates without checks.
One other way, is to have an "inbound", and a "nightly" branch. Every day, we merge in "nightly", the last green-build of the "inbound" branch which got tested by Hydra. This way we do not have a strict policy for pushing to "inbound". The only policy being that nobody merge into "inbound" if it is broken. This is the model used by Mozilla. On Fri, Oct 24, 2014 at 12:31 PM, Vladimír Čunát <[email protected]> wrote: > On 10/23/2014 08:29 PM, Domen Kožar wrote: >> >> I'm +1 on this one. Hydra evaluates nixpkgs very fast. >> >> I'm only worried if the email is per build, not per jobset evaluation. >> Is that the case? > > > I don't think it's per-build. I'd expect one e-mail per evaluation to all > who committed in-between. > > The merged PR: https://github.com/NixOS/hydra/pull/126 > > > Vladimir > > > > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
