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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux