Hi,
Currently each patch submission automatically starts two jenkins jobs for cloning, building, running tests and static checks. The longest of the two jobs can run for 30mn - 1h depending on server load. A 10 patches stack queues as many of such jobs and it can be a long process to get all votes with a significant load applied to the servers. Along with this the Allow-CI+1 label can be used by maintainers to re-trigger a job either because it failed, or the results/logs were flushed.
Per discussion with various stakeholders we come to a conclusion it would be preferable to only use the Allow-CI label and discard the automatic trigger for each and every patch. Similarly to TF-A, a change submitted by a developer requires a maintainer to apply the Allow-CI+1 label to build and run tests. For a large patch stack, the expectation is at least the top patch must pass the CI run before merging, but not necessarily all intermediate patches. It's the maintainer discretion to apply the label at different places in the patch stack to get intermediate results as required.
I intend to submit a change shortly to adopt this new policy. Let me know if any concern.
Regards, Olivier.