F42 Change Proposal: Automated Packit Onboarding (system-wide)

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

 



Wiki - https://fedoraproject.org/wiki/Changes/AutomatedPackitOnboarding
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-automated-onboarding-to-packit-release-automation-for-new-packages-system-wide/139530

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.


== Summary ==
To ease the onboarding process for package maintainers and their
release workflows, we propose to automatically create pull requests
with the initial [https://packit.dev/ 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.

== Owner ==
* Name: [[User:lbarczio| Laura Barcziová]], [[User:lachmanfrantisek|
František Lachman]], [[User:nforro| Nikola Forró]], [[User:mmasari|
Maja Massarini]], [[User:mfocko| Matej Focko]]
* Email: lbarczio@xxxxxxxxxx, flachman@xxxxxxxxxx, nforro@xxxxxxxxxx,
mmassari@xxxxxxxxxx, mfocko@xxxxxxxxxx



== 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.

== 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.

== 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.

== Scope ==
* Proposal owners:
# 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).
# Document the new process thoroughly.
# 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.

== Upgrade/compatibility impact ==
This change will not affect the compatibility/upgrade.

== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N

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

== 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.

== Dependencies ==
N/A

== 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

== Documentation ==
There is no documentation for this yet, the work needed to be done by
Packit maintainers is tracked in
https://github.com/packit/packit-service/issues/2506. The
documentation will be done as part of the work.

== Release Notes ==


-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney

-- 
_______________________________________________
devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-announce-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-announce@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- 
_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[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