According to https://travis-ci.community/t/builds-hang-in-queued-state/10250/24 and https://travis-ci.community/t/org-to-com-migration-deadline/10260 the Travis CI team had poorly communicated that the free .ORG service will cease end of this year, and projects should move to .COM. Also there is https://docs.travis-ci.com/user/migrate/open-source-repository-migration#frequently-asked-questions and https://docs.travis-ci.com/user/billing-overview/, and the timeline and discussion of options at https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works

• From the latter, the point on "I don't have enough time in my day to send off emails every few [days|weeks|months] requesting extra build credits so I can continue maintaining my open source projects." sounds all too familiar and painful...

In fact, like many others in those threads, I only found out by looking for reasons of the recent lags while the status says all systems are green. Further in the first linked thread, there are some concerns about how much and how easily FOSS projects can build in the new setup, and it is even unclear whether their free allotment is a single-time deal or a monthly quota. If a quota is overflowed, it may be possible to ask for a bump which would likely mean regular bureaucracy and lag in PR tests to live through a month, and/or possibly a more active need for sponsorship from users and companies to pay for a plan, month to month.

Alternate options include going to GitHub Actions, or spinning up free VMs in the cloud providers (some provide a way to have free low-profile services; not sure if running a builder occupying a CPU core 24/7 counts as fair use for that sort of service), or buying some VMs or physical builders, hosted at providers or at home for the community members - but again can become a matter of sponsorship in the end. On the up-side, dedicated workers can be used with varied OSes not provided by common cloud CI.

Considering recent work to build in NUT as diverse environments as we could grab (#823, #844) the availability of multiple options in Travis was certainly helpful to bring code up into shape against standards and OSes. Thanks to them for providing as much as they did in the free .ORG service, in any case.

But the future default matrix of tests, whether on Travis CI .COM or on some other solution, likely would have to be reduced to conserve their resources and to speed our PR CI turnaround:

• Spanning just an oldest available compiler with C99+__EXTENSIONS__ and gnu99, and newest compiler with newest standard, with no intermediate steps. Other related savings could include less runs with e.g. same/similar versions of same compiler in different OSes (assuming clang or gcc of same revision returns same standards-related warnings on different hosts). On the downside the contributors have less visibility on breakage they might introduce for cases they can't test locally, and the NUT team and community can't be as sure about which systems we support well and where we can improve.
• We could also clump together some of the smaller tests, e.g. shell scripts validity, to reduce the overhead of deployment and configuration vs. actual tests (Travis CI ideology did promote spinning up separate test-cases and so builders).
• Preferably the different non-default ways of building the tests should still be defined, just optional, so something like a "monthly build" could enable everything to check that we remain in shape over time but not spend resources for every build to check this is the case.