On 2 November 2016 at 05:07, David Evans wrote: > > Another reason for not canceling such a build would be to generate a record > of how many ports and which ones are > currently broken. I suspect there are a number that never get reported > because they are old or obscure or just not used > very much.
A reason for not doing this (= not not cancelling) might be a total crash of our build infrastructure that won't serve anyone anyway. We should at least: - switch to PostgreSQL - implement "successcache", so that ports with existing binary archives won't even be added to the portbuilder - implement a way to trigger rebuild of all ports without having to create artificial commits (I can imagine an additional variable on the buildbot interface or a "meta port name" like the port variable being set to "list:all" or "category:python" or "dir:perl" or "dependon:libcurl") - (useful, but irrelevant for this particular case) implement merging of commits to a single job on portwatcher - test this on a single build slave, ideally on one that's least used (perhaps on 10.8; but certainly not on the ultra slow 10.5 PPC) and only scale things once we think we are ready for a mass build. Mass builds were already problematic on the old infrastructure, but the new infrastructure is even less efficient and way more resource hungry. Mojca _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
