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

[Mateusz Kowalczyk]

On 08/08/2014 02:35 PM, Eelco Dolstra wrote:
> Hi,
> 
> On 08/08/14 12:39, Luca Bruno wrote:
> 
>> I've launched this Zero Hydra Failures (ZHF) project. Details at
>> https://nixos.org/wiki/Zero_Hydra_Failures
> 
> Great, thanks!
> 
> For reference, here is a list of nixpkgs:trunk jobs that have been broken for at
> least 6 months:
> 
>   http://nixos.org/~eelco/.bla/broken-6-months.txt
> 
> and jobs that have never been built successfully (which may include new jobs):
> 
>   http://nixos.org/~eelco/.bla/broken-forever.txt
> 
> These are candidates for not building on some platforms, being marked as broken
> or being removed.
> 
> Note the huge number of Haskell and Python packages.
> 

The problem with Haskell jobs as far as I can tell is that we often
remove old versions of packages when ‘updating’. Consider something like
QuickCheck 1.x: we update its dependencies in nixpkgs and the package
now becomes forever broken because we haven't kept the old version of
things and told QC to use that. QC 1.x is old so it's not reasonable to
go back and make it work with new dependencies: upstream won't do it and
everyone will probably use QC 2.x. If there are packages depending on
1.x then they should be updated instead.

As far as I can tell we need to do one of the following

* Remove Haskell packages which don't build with what's in nixpkgs as
long as a newer version exist. This is a problem if other packages
depend on this specific version and the only way to fix that is to make
those packages work with what's in nixpkgs or remove them too if they
are not the most recent version.

* Start preserving more package versions and start using specific
package versions.

The first solution seems preferable as it will remove the most broken
packages in the tree. I would be interested to see some kind of
statistics for how many attempted downloads there were for something
like QC 1.x: is such a statistic available? This downside is that it's
hard to tell what will break when we update a package unless we build
everything that depends on it. I think it's fine to break it once as
long as Hydra tells us and we can go back to fix it. It beats breaking
it forever.

The second solution would be a large added maintenance and Hydra burden
as the number of packages would increase dramatically. In turn we would
have binaries for a lot of versions which while nice, is probably a
waste of resources: users very often want latest version.

I think the first way is preferable (start removing things) but it's
vital that there are clear instructions for

* Adding own package versions: we often get questions in #nixos on what
to do if a Haskell package is not in nixpkgs. With this we'll need clear
instructions more than ever. So, define own Haskell package set with
packageOverrides in config.nix… Perhaps a wiki page somewhere.

* Instructions to the packagers on how to see what we're affecting when
removing a package version.

-- 
Mateusz K.