Re: Let's fix core-updates!

[Ricardo Wurmus]

Hi Chris,

thank you for taking the initiative!

> Currently, 13% of builds on core-updates fail:
>
>   https://hydra.gnu.org/jobset/gnu/core-updates

This may be a better URL:

   https://hydra.gnu.org/eval/109908?full=1&compare=master

It is a list of build failures that happen on core-updates but not on
master.  While the growing list of packages that fail to build is a
concern it is tangential to getting core-updates merged.

>   1) When is core-updates "done"?  Do we merge once we're below a
>      specific failure rate, once specific bugs have been fixed, or a
>      combination of the two?

We usually just declare it done when there are no more “big failures”.
Looking at the list of ~500 failures I see that we still have failures
that are responsible for a lot of other failures.

Take “sbcl” for example.  It is marked red, which means that it failed
not because one of its dependencies failed to build, but because there’s
something wrong with it.  Sbcl is needed for all the “sbcl-*” packages,
which are also needed for “uglify-js”, which in turn is needed for
pretty much all of the failing “r-*” packages and for all of the “js-*”
packages.

So, fixing the “sbcl” package appears to be important.

The next thing that stands out to me is the long list of “java-*”
packages that are marked brown, indicating that a dependency failed to
build.  Turns out that “java-hamcrest-all” fails to build.  The build
error is … strange.  But maybe we can ignore the Java stuff if we can
merge the dedicated Java updates branch right after merging
core-updates.

>   2) How shall we prioritize and divvy up work for fixing the failures?
>      I'm guessing people just need to volunteer and start debugging!

Only the red packages really need investigation.

I’ll take a look at these packages:

- augeas
- knights
- python-ipy
- sbcl

For sbcl we may just be able to upgrade to the latest version.  I’m
going to give that a try.

>   3) Are there any tools to help us understand what the failures might
>      have in common?  E.g., if half the failures occur because a package
>      deep in the dependency graph fails to build, clearly that package
>      should be prioritized for fixing.  I suppose we'll learn about
>      commonalities as we go, but it'd be nice if there were a tool that
>      might help us understand what to focus on first.

I don’t know of any.  We can look at the logs of brown packages to see
if we can detect any common dependency failures (as with sbcl above) and
we can look at the output of guix graph.  But there’s nothing else I can
think of.

>   4) What other bugs/features need to be addressed to un-block release?

The next release primarily depends on core-updates.  As a bonus we can
fix a couple more bugs in the bug tracker.  I don’t expect us to cut a
new release right after the merge of core-updates, but that’s the
biggest part of it.

> I know that we want to update the default JDK used by Java packages from
> 7 to 8, but there are probably more important tasks to finish up, also.

Yes, I’d like to get this branch merged before the new release, because
it’s not far from completion.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net