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

[Luca Bruno]

@peti: the recent hydraPlatforms change is a hack right? Because that does
not prevent the user from trying to install the package, which will be
compiled and will fail.


On Fri, Aug 8, 2014 at 10:45 PM, Luca Bruno <lethalman88 at gmail.com> wrote:

> 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
>



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