Here is the summary of recent voting: https://docs.google.com/document/d/1DClOxQADo-KqC18KK-RPmz2awRNpRt1W5z_xnWfMFd8/edit?usp=sharing Quick summary - topics sorted by priority (higher got more votes for priority]: * better automatic builds triggered by github, gitlab... * More parallel builds * runtime dependency config between copr projects, so `dnf copr enable <user/foo>` enables other projects transitively * Mock development * run lints like rpmlint or rpm-inspect after each build * new commands for our API and copr-cli * allow you to vote for quality project with thumbs up/down and high quality repos automaticaly promote and allow you to enable as one big repo of "editors pick". * add RHEL as target * automatically rebuild PyPI and Rubygems * focus on rpm spec generators * build Flatpak application from your project * add emulated architecture s390x Thank you for the participation. It means a lot for us. If you miss specific triggers or API calls, please file them on https://pagure.io/copr/copr/issues Feedback to some comments: > Simplified and integrated this chain: Playing with package in Copr → Review Request package from Copr and import it to RHBZ in one click. > Simplify "promotion" of COPR packages to regular Fedora package (something like a "one click review request") We want first to focus on automatically determine quality of the package/spec file. That was one of the topics to consider. Once we will give an user basic guidance we can offer submission to package review. > ability to run copr locally on local hardware in a reasonable number of steps Copr as build system? We have Docker compose, which can spin up Copr in one command. We have public playbooks which deploys Copr in Fedora infrastructure. We are going to run in OpenShift soon and there will be template available soon. I am not sure if we can do more. > Automatically postpone createrepo runs if there are more builds for the same repo pending. Then, run createrepo just once after the last build. We have this implemented on backend, because this was needed for modules. We just need to expose this in API and WebUI. You can expect it in near future. > max successful builds option This is already available. See previous thread. It is in chroot setting. > make copr more responsive? I will consider removing several sleep()s :)) Jokes aside. Yes, we are trying to do our best. > Automatic rebuilds triggered by updates of build dependencies of packages in repos used for building packages This is what Koshei does. While some integration is possible, we have no idea or plans on radar. > API tokens for groups (avoid ned of creation of fake users for teams) Good idea. > A very useful documentation about COPR guideline for both maintainers and developers. User friendly, clear and concise please We have https://docs.pagure.org/copr.copr/user_documentation.html https://python-copr.readthedocs.io/en/latest/index.html I collaborate on: https://rpm-packaging-guide.github.io/ The documentation can be **always** better. If you miss specific steps or parts, please let us know. Or even better - contribute. The source of documentation is open. > Mass rebuild handling, including bootstrap phases Yes. Thou, this is complex. If you have ideas for some low hanging fruits, then let us know. > This is kinda big, but it keeps me away from Copr: I'd like copr to closely resemble packaging for Fedora, down to every signle command. This way we can have playground in which we can practice packaging before applying to be packagers. I'm pretty intimidated by discussions I see in packaging world, and would like to start slowly on my own time - by using Copr. I am FedoraUser fwiw. I understand this. Thou I do not believe this will ever happen. Fedora builds in Koji. Copr has different goals, different audience, different UI. We are looking that direction. > getting this ASAP since it blocks building java stuff on CentOS Stream / EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1572596 We are already working on this. It should be in next release. -- 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
