On 04/03/16 16:42, Martin Lucina wrote:
I think we now need a policy for packages which do not build -- I don't want
to perpetually advertise a broken build in case there's a package that
nobody wants to fix in a reasonable amount of time. We could just mark a
package broken the first time it fails to build, file an issue, and remove
the broken tag once the package is suspected to be fixed; rinse+repeat. The
fancier option to list packages which are known to be broken and don't
affect the 0/1 build result, but nonetheless we keep on building the broken
package. The latter gives us finer-grained detection of regressions, but
requires more work. I'd just go with the first option for now. Thoughts?
The main problem with this approach (removing a failing package from a
build) is that right now there's no easy way for a maintainer to test that
their package builds *on Travis*. This is relevant for e.g. the
currently-failing OpenMP package. Asking maintainers to fork the
repository, set up a Travis account and run their own builds is suboptimal.
How exactly does the sentence with "suspected to be fixed" not address
your concern?
IMHO the best thing to do would be to eventually change to a Dockerized
build with one "build container" per package, that way at least anyone with
Docker installed can replicate a build locally (or anywhere with Docker).
The reason I've not done that yet is because I wanted something that works
ASAP and doesn't depend on anything except Travis.
Depending on Docker is a no-no, just like pushing for any other
non-universally available host features.
