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

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

macports-dev mailing list

Reply via email to