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

Luca Bruno lethalman88 at gmail.com
Fri Aug 8 22:45:57 CEST 2014


That's a good idea for the long-term. However the mechanism for which we
decide that a package is buildable with python2 but not python3 is still a
work in progress. Same goes for other languages like haskell.
So before reaching that automation level it's necessary to step through
this rough problem first.


On Fri, Aug 8, 2014 at 10:40 PM, Alexander Kjeldaas <ak at formalprivacy.com>
wrote:

>
>
>
>
> On Fri, Aug 8, 2014 at 12:39 PM, Luca Bruno <lethalman88 at gmail.com> wrote:
>
>> I've launched this Zero Hydra Failures (ZHF) project. Details at
>> https://nixos.org/wiki/Zero_Hydra_Failures
>>
>> The hydra instance at nixos.org has lots of build failures, it's a huge
>> percentage over the total. The aim of this project is to drop failures to
>> zero.
>>
>> I invite all contributors to take some time reading the project page.
>> Trying to build a package, fixing or marking it as broken takes less time
>> that you might imagine. It's not as time-expensive as it would be for a
>> package that you are interested in.
>>
>>
> I'd like to float an alternative path.  We know that the output of a
> successful build is a set of files.
>
> But what is the output of a failed build?
>
> I suggest that it should be a suggestion for a fix.  When a build breaks,
> it shouldn't just stop dead.  Rather, the build system should call an
> exception handler that over time could become pretty sophisticated.
>
> For example, for the failed python builds, this exception handler could
> check whether a successful build exists for another python version.  If so,
> suggest a patch that blacklists the python  version that was currently
> used.   A general rule could be that if it builds successfully on another
> platform, blacklist this platform.
>
> These "suggestions" could be full-fledged git branches ready for a pull
> request, commits or just edits in a local nixpkgs tree.
>
> This is probably some work, but some perl hacks that work for certain
> regular nix expression layouts could potentially work for a lot of packages.
>
> To simplify auto-editing, a fairly strict syntax could be used for certain
> meta-data so that simple perl regexps + grep would be enough for most of
> the blacklisting/whitelisting work.
>
> Alexander
>
>
>
>> Best regards,
>>
>>
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>


-- 
www.debian.org - The Universal Operating System
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140808/5f988e7a/attachment-0001.html 


More information about the nix-dev mailing list