Sorry, guys, I wasn’t receiving notifications about these messages (does anyone know how to enable them?). Peak cancelled. As @msuchy explained, builders are distributed among users, so that a long queue for one user doesn’t hold all the resources. Anyway, I didn’t know about these “background” jobs (I think it should be better documented), so I’ll submit batches using the background flag from now on.
It would be great, though, if this wasn’t necessary. When the pending queue for a particular repo grows above some limit, builds could be automatically marked as background. The limit could depend on the number of builders available and the number of users submitting builds. Just an idea.
@sbonazzo: I was told that this was a fair use case when I started the project. I think that Copr should be able to deal with such projects (and the command line tools and APIs provided should be adequate to such projects; currently, they are not). At the very least, this project has served to identify some bugs and RFEs.
So is it really needed to rebuild all CRAN repository? I believe it is. CRAN provides binaries for Windows and MacOS, but not for Linux. This is why Debian/Ubuntu has had for years a similar initiative to maintain a non-official repo for most of CRAN. Fedora has only a few hundred R packages in the official repositories, and maintaining them is already a huge task. So this Copr repo is meant to fill this gap.