Do you want to contribute to Copr?
I had a realization at this year’s DevConf. Even if people want to contribute to large open-source projects, they have no idea how. Or they don’t even realize they can contribute in the first place and that such a thing would be appreciated That’s why I wanted to try this experiment and offer 5 interesting RFEs for the Fedora community to implement.
Why you should contribute
Copr is a build system and third-party package repository for RPM-based distributions. It’s similar to AUR for example. The project has been around since 2012 and has become an integral part of the Fedora packaging ecosystem, as corroborated by many conference talks and articles mentioning it. We currently host 29000 projects from 7000 Fedora users and the package downloads are in millions.
At this moment, there are 275 valid and triaged issues and RFEs in the issue tracker. On this board, you can see the roadmap for the upcoming months, years, and possible futures. One obvious reason for contributing to the project is getting a feature implemented sooner. Another reason is to improve your skills as a software developer. It may be more fun and more useful than creating a new TODO application from scratch. Last but not least, it’s never a bad idea to show your skills and collaborate with people who can do job referrals. That’s how I got my dream job 9 years ago. I think this is a great opportunity for students looking to get some infield experience during the summer break.
Don’t worry if you don’t feel competent enough to contribute. We have documentation for setting up your local development environment, tests and a review process to improve the code quality, and a Matrix channel for more informal communication. If you ever get stuck somewhere in the process, please ping me and mention this article.
How you can contribute
Of course, you can pick any issue from the Copr issue tracker that seems interesting to you. Or you can pick any other project for that matter, help is appreciated everywhere. However, In this article, I wanted to put together a list of interesting and useful RFEs that our team won’t have time to implement in the near future. Please let us know if you would like to collaborate with us on any of them. We will get you started and make sure you have all the information you need.
1. External repository validation
| Difficulty: | Trivial |
|---|---|
| Required skills: | Python |
| Ticket: | fedora-copr/copr#1178 |
| Contributor: | @jaitjacob |
Copr projects can depend on other projects. It is possible to specify such a
dependency via a fully qualified URL or a shortcut in the copr://owner/project
format. It would be nice to have a validation making sure that users cannot set
a dependency on a non-existing project (due to typos for example).
2. Possibility to force delete a project
| Difficulty: | Easy |
|---|---|
| Required skills: | Python |
| Ticket: | fedora-copr/copr#2629 |
| Contributor: | @ProfessorCode |
Through the Copr CLI utility, it is possible to delete an existing project with all of its builds. This, however, fails when some of the builds are not yet finished. We would like to improve the respective API endpoint to automatically cancel all running builds, making sure that no matter the state of the project, it can be deleted.
3. Dark mode support
| Difficulty: | Medium |
|---|---|
| Required skills: | HTML, CSS, Javascript |
| Ticket: | fedora-copr/copr#3150 |
The Copr website offers only one theme and that is black text on a white background. According to many online articles, dark-mode web designs are getting increasingly more popular, helping to reduce eye strain and power consumption. We would like our users to have the option to choose whether they prefer light or dark mode of the website.
4. Webhook history
| Difficulty: | Medium |
|---|---|
| Required skills: | Python, HTML |
| Ticket: | fedora-copr/copr#304 |
| Contributor: | @jaitjacob |
Copr provides integration with Git forges like GitHub, GitLab, and Bitbucket through webhooks. Usually, everything works smoothly. However, when builds are not being triggered when they should be, or conversely, when they are triggered multiple times, it is hard for users to debug the issue. We would to have a table of all received webhooks. This would allow project owners to understand what exactly happened.
5. Actions overview
| Difficulty: | Hard |
|---|---|
| Required skills: | Python, HTML |
| Ticket: | fedora-copr/copr#1108 |
Copr is a complex system, requiring various so-called “actions” to run in the background. For example, in a project overview, there is a button for regenerating the project repositories. When clicked, it triggers an asynchronous action which is performed on an entirely different server. It usually takes seconds to complete but it may take longer depending on the current queue. It may even fail for some unexpected reason. Project owners have no way of knowing what actions affected their projects and whether they finished successfully. We would like to have a table for every project, showing all the actions that happened.