Copr Build System - review of 2019 and vote for features in 2020

[Miroslav Suchý]

I want to sum up what happened in Copr during 2019. At the end of this email, you can see
our TODO list and cast your
vote on what we should focus on.

During the year 2019:

* we added native AARCH64 builders
* we added emulated ARMhfp builders
* released eight new versions of Mock including features as Jinja templates in configs,
Dynamic BuildRequires,
subscription-manager support, which enables us to build on top of RHEL, Fedora Toolbox
support, and container image
support which allows building using incompatible RPM.
  https://github.com/rpm-software-management/mock/wiki#release-notes
  To give credit - some of these Mock's features were contributed by community
members.
* We removed outdated chroots, which allowed us to reclaim terabytes of disk space. At the
same time, we give you the
option to keep those old repos if you want them.
  http://frostyx.cz/posts/copr-removing-outdated-chroots
* we provided RSS feed
  https://fedora-copr.github.io/posts/Copr-new-rss-feed
* we added project discussions by integration with https://discussion.fedoraproject.org
* your project can be marked as temporary, and we delete it automatically after a
specified amount of days. This is
great for CI projects.
* we migrated from fedmsg to fedora-messaging
  https://pavel.raiskup.cz/blog/copr-messsaging.html
* we provide anonymized DB dump so that you can play with our data
  https://copr.fedorainfracloud.org/db_dumps/
* you can pin your favorite projects now
   http://frostyx.cz/posts/create-your-portfolio-with-pinned-projects
* thanks to Amazon, we can use AWS for builders for free, which allowed us to use more
builders.
* user Iucan rebuilds all R packages from CRAN for Fedora
 https://copr.fedorainfracloud.org/coprs/iucar/cran/
* we are contributing to speed up createrepo_c, because that one is our biggest
bottleneck. For projects like Cran or
python rebuilds, the createrepo task runs longer than the build of package and cannot be
parallelized.
* Many interesting projects appeared in Copr and we wrote about them
 https://fedoramagazine.org/?s=cool+new+projects+to+try+in+COPR
* Added per-package config option to blacklist the package from building against
particular chroots
* Added support for multilib projects https://pagure.io/copr/copr/issue/1181
* Refined modularity support, module dependency, module_hotfixes flags, ...
* Copr permissions can now be set via API and CLI.
* Removing old builds automatically, per option that only keeps a maximum number of builds
per given package.

What are our plans for 2020? We have some mandatory tasks:
* migrate to new datacenter together with the whole fedora-infrastructure
* install and use new and bigger storage

Yet we have quite a long list of RFEs and tasks to do. As **you** are our customers, I
would like to hear your opinion
on what is crucial for you.
Please cast your vote here:
  https://forms.gle/GXWaZ1yzmkPJmeQw9

Options:
 * allow more parallel builds - everyone wants faster builds. I am afraid we cannot speed
up the build itself, but we
can focus on allowing us to run more builds in parallel to handle peaks.
 * Mock development - we spend a lot of time on Mock development. We utilize those new
features in Copr, but they are
useful even for your local workflow with Mock. Should we spend more time on longstanding
RFEs?
 * build Flatpak application from your project - we have a viable idea how to build
Flatpak app from your project with
just a few clicks, and we can upload the result to some registry. E.g., to
https://quay.io/
 * new commands for our API and copr-cli
 * run lints like rpmlint or rpm-inspect after each build and give you hints on how to
improve your spec files
 * automatically rebuild PyPI and Rubygems - we already did this in the past, but we did
not rebuild it for new Fedoras
 * allow you to vote for quality of the project with thumbs up/down and high quality repos
automatically promote and
will enable them as one big repo of "editors pick".
 * focus on rpm spec generators - See
https://docs.pagure.org/copr.copr/user_documentation.html#scm what we support
right now.
 * add emulated architecture s390x - while we would like to add native architecture, it
will likely not happen next
year, but we can do builds using QEMU.
 * add RHEL as a target - right now you can build on top of CentOS, but we can allow you
to build on top of RHEL
 * better automatic builds triggered by GitHub, Gitlab, aka mimic the Copr CI we have for
Pagure - git server sends
request - copr replies back with build status
 * runtime dependency config between copr projects, so `dnf copr enable <user/foo>`
enables other projects transitively
 * something else - is something blocking you from using Copr? Please share it with us.


Please cast your vote here:
  https://forms.gle/GXWaZ1yzmkPJmeQw9


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys