F42 Change Proposal: Automated onboarding to Packit release automation for new packages (system-wide)

Project Discussion Change Proposals
,
1

Automated onboarding to Packit release automation for new packages

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

To ease the onboarding process for package maintainers and their release workflows, we propose to automatically create pull requests with the initial Packit configuration file for newly created projects at src.fedoraproject.org. Once merged, this configuration will enable Packit to automate the release process, reducing repetitive tasks for maintainers.

:link: Owner

:link: Detailed Description

This proposal introduces a mechanism to simplify the onboarding of Fedora package maintainers to Packit by removing the need to create the configuration manually. When a new project is created at src.fedoraproject.org, a pull request with a default Packit configuration file will automatically be opened.

Our proposal would be to add a CLI argument to the fedpkg request-repo command, similar to the existing argument --monitor. By default, this argument would be enabled and it would result in a Packit pull request being created upon the creation of a new repository. For maintainers who prefer not to have a Packit pull request created, this can be easily disabled by setting the relevant CLI argument during the repository creation request.

Once the pull request is merged, this configuration will:

  • Automate the process of opening pull requests for updates when upstream releases occur (triggered by Upstream Release Monitoring), including necessary changes to the spec file and sources.
  • Handle subsequent Koji builds and Bodhi updates after the pull requests are merged by the maintainer.

The automation would be configured by default to operate only on rawhide.

This ensures that maintainers no longer need to spend time on repetitive release-related tasks. Instead, they can focus on package quality and innovation. The pull request will also contain detailed instructions explaining:

  • What is Packit and how the default configuration works.
  • How maintainers can customize it to suit their project’s needs, such as disabling certain tasks.
  • The steps to opt out of the automated pull request process.

:link: Feedback

Discussions have indicated an interest in opt-out possibilities. As mentioned above, our current proposal would be implementing the opt-out via a CLI argument when requesting the repository creation.

:link: Benefit to Fedora

This change aims to:

  • Simplify the initial setup process for using Packit, reducing barriers for Fedora package maintainers.
  • Decrease the time and effort spent on repetitive release-related tasks, allowing maintainers to focus on their packages’ quality and innovation.
  • Provide maintainers with clear guidance and support for customizing or opting out of automation to ensure the system is flexible and user-friendly.
  • Introduce Packit to maintainers as they create new packages, starting with typically simpler projects that are easier to automate, making it a good opportunity for them to learn about Packit.

:link: Scope

  • Proposal owners:
  1. Implement automated pull request creation and integrate it into src.fedoraproject.org workflows (probably via fedpkg request-repo command and the related scripts for repo creation).
  2. Document the new process thoroughly.
  3. Followup support for users in the created PRs.
  • Other developers:

This will be very isolated change that shouldn’t require much (if any) work done by other developers. If we contribute the code to the repo creation functionality, we would just need some guidance/review on these changes.

  • Release engineering:

Coordination with release engineering is not required. A mass rebuild is not necessary for this change.

  • Policies and guidelines:

Packaging guidelines should be updated to describe this process and the opt-out option, after the implementation is done.

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

This proposal aligns with Fedora’s strategy of improving contributor experience and easing workflows, supporting a more efficient and user-friendly ecosystem.

:link: Upgrade/compatibility impact

This change will not affect the compatibility/upgrade.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

:link: How To Test

Requesting a new repo in src.fedoraproject.org should result in pull request with Packit configuration being created for that repo.

:link: User Experience

With this change, package maintainers will experience:

  • Automated pull requests containing default Packit configuration files for newly created projects at src.fedoraproject.org.
  • Clear explanations and instructions within the pull requests to help them understand the configurations and make necessary adjustments.
  • The ability to quickly get started with Packit without needing to manually create configuration files.
  • An opt-out option for those who prefer not to/can’t (their packages are not suitable for this kind of automation) use Packit.

Once the Packit configuration is merged, the release process will be almost fully automated. This includes:

  • Opening pull requests for required updates when upstream releases occur.
  • Performing Koji builds and Bodhi updates automatically after merging the updates by the maintainer.

This automation significantly reduces the repetitive workload for maintainers, allowing them to dedicate their time to improving package quality and addressing other critical aspects of their projects.

:link: Dependencies

N/A

:link: Contingency Plan

This feature is technically not really tight to the new Fedora version.

  • Contingency mechanism: N/A
  • Contingency deadline: N/A
  • Blocks release? No

:link: Documentation

There is no documentation for this yet, the work needed to be done by Packit maintainers is tracked in Open PRs with Packit config for new Fedora packages ¡ Issue #2506 ¡ packit/packit-service ¡ GitHub. The documentation will be done as part of the work.

:link: Release Notes

Last edited by @amoloney 2024-12-12T14:18:56Z

Last edited by @amoloney 2024-12-12T14:18:56Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

I am against making this opt-out instead if opt-in. Adding a flag to fedpkg to set up packit is a nice idea, but I don’t think it’s a good idea to do it unconditionally. At least for some kinds of packages, packit makes it currently too easy to shoot yourself in the foot (or rather, shoot at other people’s feet).

4

Likewise, a flag in fedpkg request-repo makes sense, but not doing it unconditionally. We also let people configure whether release-monitoring is active at this time, and I don’t see a reason why we wouldn’t offer this there too.

5

I am fine with opt-in by default because what you are opted-in automatically is receiving a PR in dist-git. The maintainer still has the option to merge or close that PR.
If you are not planning to use Packit and don’t want the noisy PR then you can use the flag in fedpkg request-repo.
But generally, I think that having the PR open by default is a great way to increase awareness and adoption of Packit :+1:

1 Like
6

Can we please strat by making this opt-in and only later consider changing the default?

7

Thanks, everyone for your quick responses!

This is exactly the reason why we (~Packit team) prefer to have it opt-out – the aim of this is to have a way how we can introduce Packit to people that do not know about it. (And of course, make it really easy to set up). And if we go with an opt-in way, people who don’t know about Packit would not know about this option as well… Which significantly reduces the effect of all this.

Still, this is not enabling Packit by default, but sending a pull request that can be closed.

(But I understand the reasons you want to be cautious.)

8

For the monitoring setting, the default is the monitoring enabled, so with Packit, we wanted to do this exactly like that. A user requesting the repo could still set this option to disable the PR creation.

9

Isn’t it effectively opt in? The opened PR will actually contain configuration to enable Packit. So if it is merged, then Packit will be enabled. If the PR is closed, then Packit is not enabled.

5 Likes
10

What if users who don’t know any better will start using packit in a way that disrupts others?

11

Can we have an example of how the PR would look like?

12

I hope pull requests can help here:

  • We have a place in the form of a description to give users enough info about Packit and also to warn or provide what they still need to pay attention to.
  • There is a place for discussions and questions. It wasn’t mentioned explicitly in the proposal, but we want to monitor these pull-requests and provide guidance if/when needed.
1 Like
13

We’ll try to mock something. If it helps, we can also prepare description text for review so we can agree on all the concerns and warnings that might be included. (We just need to be careful not to scare the user by the amount of text…:wink:

1 Like
14

One more note to this. I would be interested in real examples of this behaviour so we can try to avoid this (code, docs, letting users know, …)

1 Like
15

OK. I guess you convinced me, as long as we review the PR description together as part of this discussion. I think that it needs to explicitly say that the packagers need to review all the packet PRs and ensure that the update does not break other packages. Ideally with some tips (or a link to some page with tips – if we don’t have any, I can help draft some).

1 Like
16

Case 1: Packagers merge and autobuild packit update, breaks others

  • last time it was libphonenumber soname bump (do not recall which of the updates was it)

Case 2: Packagers setup packit, ignore the PRs, spam others

https://src.fedoraproject.org/rpms/python-textual/pull-request/2
https://src.fedoraproject.org/rpms/python-textual/pull-request/4

1 Like
17

The easiest example would be packit submits a PR for a “breaking” version update, I think.

Since we don’t have reverse-installability tests, these issues would be invisible in packit-PRs (scratch build and installability tests would succeed, but actually pushing the update would break dependent packages).

This is mostly a problem for Python and Rust, as far as I can tell - where packages often use version bounds for their dependencies like >=1,<4 or something like that. A packit-filed PR for version 4.0.0 would look perfectly fine (scratch build passed, installability tests passed, etc.) but pushing it would break dependent packages.

I don’t think there would be a good automated process to check for this without also implementing reverse-installability tests in the CI pipeline (a feature that has been requested for years).

1 Like
18

Thanks for the example @decathorpe , I’ll add an explicit note about this into the description that it’s (still) on maintainer to check this.

Also, we can do more marketing for version_update_mask config option that can skip bigger version jumps. (I know one can’t really just on this but at least a bit of help in this field. The maintainer should be the one to know thier package the best.

We would like to do something about this as well…:wink: But definitely not soon…:wink: We’ve done research about reverse-dep tests/builds earlier this year and started a discussion with the Koschei maintainer but there are multiple other tasks that need to be done before this. (But I agree it’s really an important thing.)

19

As promised, here’s a text of the description for review. Please, take a look. Suggestions are welcome.

And I’ve also created an issue to create a separate doc page about all the information as suggested so we can link it both from onboarding pull requests but also from the sync-release ones.

20

Based on the PR description text, I assume you would be turning this on for multiple Fedora releases. Pckagers violating Updates policy :: Fedora Docs is another concern I have.

Updates should only happen in rawhide and be cherry-picked or merged to stable branches based on their severity and dangerousness. Since this is very easy to do wrong, I am strongly advocating for the default to do rawhide only.