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

[Domen Kožar]

I think the following steps could be done without too much damage:

- IRC bot that reports build failures for a range of commits once
nixos-combined jobset is done

- email to commiters that broke the the build (with a range of commits and
list of builds failed)

- nixos channel updates only when there are zero failures on jobset (this
would mean reverts will happen often - and I believe that's the correct way
to go instead of blocking people and punishing good testers)

- encouragement of "nox-review wip" use. This will bulid also all
reverse-dependencies (good old Gentoo times)

- ease of bisecting failures (for 99% of use cases this could be a range of
commits done for jobset with test script respecting exit code of nix-build)
- it could be even done as a separate service or part of hydra or just a
copy/paste command for local testing

All that being said, there are still number of false positives that will
drive people crazy. Mostly due to networking issues and transient failures
in build systems (mostly during testing phase). We should address them one
by one and reduce hard unpurities. I've already done so as part of ZHF, but
much more work is needed.


On Mon, Oct 27, 2014 at 7:33 PM, Michael Raskin <7c6f434c at mail.ru> wrote:

> >On Sat, Oct 25, 2014 at 05:45:34PM +0200, Nicolas Pierron wrote:
> >> 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.
> >>
> >
> >Just being completely honest here, I will be less likely to contribute
> >things I don't need urgently if I have to open a PR and wait even after
> >testing locally.
>
> And let's be honest even further: we need to go ahead quickly, our value
> is not in making mistakes rarely, it is in the ease of fixing them. We
> are not yet in the state where freezing it and maintaining stability is
> a good idea.
>
> I am afraid that the only good thing that can come from the quest for
> stability would be a well-tested way to support overlays.
>
>
>
> _______________________________________________
> 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/20141027/84e184fb/attachment.html