[Nix-dev] Zero Hydra Failures (ZHF) project for NixOS

[Georges Dubus]

I have a few plans that might help with this:

- Try to improve travis (which will only possible to some point, because
it's not hydra) ;
- Have a bot post on each pull request the list of attributes touched by
the PR, encouraging people to try to build them all (and improve nox-review
to make it easier);
- Prepare a proposition to switch to a bot-driven workflow for the PR, in
which a bot does the merging: this lets us choose any rule we want for the
merging. For example, PR are merged into a specific branch after
acceptation by a collaborator and passing some tests.

It all comes down to the firepower of hydra. Encouraging people to check
the build themselves is just a way to distribute computations we don't have
the power to do. I'd love to have enough computing power to establish a
workflow in which every PR is checked before it's merged into master or,
even better, every PR is checked as soon as it is created.

Georges Dubus

2014-10-25 18:07 GMT+02:00 Michael Raskin <7c6f434c at mail.ru>:

> >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.
>
> We need a PR fireman already…
>
> And Travis still has false-failure rates that eclipse the worst failures
> of Hydra.
>
> >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.
>
> I guess we could keep more or less the same policy as for current master
> («remember, some people try to use the master branch on their systems»)
> with this split.
>
> Maybe fireman work could be reduced to «it's OK to revert if it breaks
> something on Hydra».
>
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20141025/49f92a5c/attachment.html