On Wed, Jan 30, 2013 at 02:23:28PM +0100, Andres Loeh wrote: > >> haskellPackages_ghc6104 = recurseIntoAttrs > >> (haskell.packages_ghc6104); > >> haskellPackages_ghc6123 = recurseIntoAttrs > >> (haskell.packages_ghc6123); > >> haskellPackages_ghc704 = recurseIntoAttrs > >> (haskell.packages_ghc704); > >> haskellPackages_ghc741 = recurseIntoAttrs > >> (haskell.packages_ghc741); > >> haskellPackages_ghc742_no_profiling = recurseIntoAttrs > >> (haskell.packages_ghc741.noProfiling); > >> haskellPackages_ghc742_profiling = recurseIntoAttrs > >> (haskell.packages_ghc741.profiling); > >> haskellPackages_ghc742 = recurseIntoAttrs > >> (haskell.packages_ghc742.highPrio); > >> haskellPackages_ghc761 = recurseIntoAttrs > >> (haskell.packages_ghc761); > >> haskellPackages_ghc762 = recurseIntoAttrs > >> (haskell.packages_ghc762); > > > > This number of builds is not really a problem for Hydra, but it is for the > > binary channel generation: the NixOS and Nixpkgs channels are only updated > > after > > *every* package in the latest jobset evaluation has been built and > > mirrored. So > > having 71% of the channel consist of Haskell packages adds considerable > > latency. > > > > I would suggest removing most of the GHC versions from the channels (i.e. > > remove > > "recurseIntoAttrs"), except the default (7.4.2) and the latest (7.6.2). If > > desired, we could create a separate Hydra jobset to build the other > > versions. > > At the moment, this would be fine. I'm hardly using anything that's > older than 7.4.2 right now. There are phases in GHC development though > where having builds for three different versions is really helpful. > > Creating a separate Hydra jobset might be a good option, but I have no > experience with how that's done.
Hello, yes, I think it would be nice, if nixpkgs/trunk were free of the haskellPackages clutter, specially in the job list / status overview. Hydra does on-browser folding in some places, like logs; maybe adding folding to the statusOverview / job list would be good, instead. _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
