On Friday, 04.03.2016 at 16:53, Antti Kantee wrote:
> 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?

Sorry, I missed that, it was a long sentence :-)

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

Sorry, I wasn't clear. I don't mean "make the packages build depend on
Docker". I mean "make the *Travis* build depend on Docker". That way,
anyone could replicate the exact same build locally when testing, and do so
at their leisure without having to wait for Travis. That seems like an
advantage to me.

Reply via email to