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

[Raahul Kumar]

Thanks for your hard work Domen, much appreciated.

How do we cut down on the false positives? Can we insert someone in the
middle who will test them out and say yes or no?
Any other way?

Aloha,
RK.

On Tue, Oct 28, 2014 at 4:40 AM, Domen Kožar <domen at dev.si> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/20141030/be00282a/attachment.html