From Fedora Project Wiki
(hint MVP, add simple workflow)
(finish workflow and mvp)
Line 3: Line 3:
 
'''This SIG is a work in progress and will be announced properly once we're ready, stay tuned.'''
 
'''This SIG is a work in progress and will be announced properly once we're ready, stay tuned.'''
  
We would like to offer and alternative way to maintain Fedora Linux packages in comparison to [[Package_maintenance_guide|the traditional way via dist-git]].
+
We would like to offer an alternative way to maintain Fedora Linux packages in comparison to [[Package_maintenance_guide|the traditional way via dist-git]] which should be more convenient to maintainers and require less manual actions.
  
 
=== Rules ===
 
=== Rules ===
  
 
* Whatever we produce here, it MUST NOT violate Fedora Packaging Guidelines (we should strive to change them if needed).
 
* Whatever we produce here, it MUST NOT violate Fedora Packaging Guidelines (we should strive to change them if needed).
* Maintainers HAVE TO be able to step in for automation and replace some of its actions if needed.
+
* Maintainers HAVE TO be able to step in for automation and replace some of its actions if needed. The automation NEEDS TO handle such situation.
* Proven packagers and rel-eng still needs to be able to do their work in dist-git: their workflows NEED to keep working the same way.
+
* Proven packagers and rel-eng still needs to be able to do their work in dist-git: their workflows MUST NOT be dirupted.
  
 
=== Goals ===
 
=== Goals ===
Line 17: Line 17:
 
==== Easier maintenance for rawhide ====
 
==== Easier maintenance for rawhide ====
  
Updating "simple" packages in rawhide should be as easy as merging a PR in dist-git if all tests and checks pass.
+
Updating packages in rawhide should only require changes in the packaging files and approving PRs.
  
 
===== Workflow =====
 
===== Workflow =====
  
1. Set up a source-git repository manually on a packit-supported platform (github.com, gitlab.com)
+
# Set up a source-git repository manually on a packit-supported platform (github.com, gitlab.com)
  * This includes creating a specific branch and setting up jobs for packit-service to handle events.
+
#* This includes creating a specific branch and setting up jobs for packit-service to handle events.
  * CI is set up (such as [https://packit.dev/docs/testing-farm/ Testing Farm]).
+
#* CI can (and should) be set up (such as [https://packit.dev/docs/testing-farm/ Testing Farm]).
2. Anyone in the community is able to interact with this repository the same way with any other open-source project.
+
 
3. Packit-service should accept an event when a new upstream release is done (via [https://release-monitoring.org/ Upstream Release Monitoring]).
+
# Anyone in the community is able to interact with this repository the same way with any other open-source project.
4. Packit-service creates a pull request which contains the new release in the repository.
+
 
  * A dist-git PR is created in parallel. Downstream checks are synchronized to the source-git PR.
+
# Packit-service can accept events when a new upstream release is done (via [https://release-monitoring.org/ Upstream Release Monitoring]).
5. The owner of the source-git repository reviews and updates the pull request as needed.
+
 
6. Once approved, dist-git PR is merged first and packit-service triggers a build. If the build passes, source-git PR is merged as well. If the build fails, source-git PR is updated a new dist-git PR is created and this step happens again.
+
# Packit-service creates a pull request which contains changes to bring the new release to Rawhide.
 +
#* A dist-git PR is created in parallel. Downstream checks are synchronized to the source-git PR.
 +
 
 +
# The owner of the source-git repository reviews and updates the pull request as needed.
 +
 
 +
# Once approved, dist-git PR is merged first and packit-service triggers a build in Rawhide. If the build passes, source-git PR is merged as well. If the build fails, source-git PR is updated a new dist-git PR is created and doing the cycle of this step again.
 +
 
  
 
==== More convenient way to work on downstream patches ====
 
==== More convenient way to work on downstream patches ====
  
Track patches as git commits. This way it's easier to backport or cherry-pick changes from the upstream and rebase the patches when a new upstream release happens.
+
Downstream patches are tracked as git commits. This way it's easier to backport or cherry-pick changes from the upstream and rebase the patches when a new upstream release happens.
 +
 
 +
* Commits can be picked up easily the same way as in any other git repo.
 +
 
 +
* Patch file names can be configured.
 +
 
 +
* Patches are automatically added to spec file.
  
  
 
==== MVP ====
 
==== MVP ====
  
The "product" of this SIG should be implementation of a following MVP. Once that's done, we'll evaluate where we want to head next.
+
The "product" of this SIG should be implementation of a following MVP. Once that's done, we'll evaluate what should be the next steps.
 +
 
 +
* Source git repos can be easily created, set up and this is well-documented.
 +
 
 +
* New upstream releases are automatically brought into the source-git repos when configured.
 +
 
 +
* Changes pushed to source-git repos are automatically proposed downstream for inclusion in dist-git.
 +
 
  
 
== Members ==
 
== Members ==

Revision as of 15:40, 24 March 2021

Mission

This SIG is a work in progress and will be announced properly once we're ready, stay tuned.

We would like to offer an alternative way to maintain Fedora Linux packages in comparison to the traditional way via dist-git which should be more convenient to maintainers and require less manual actions.

Rules

  • Whatever we produce here, it MUST NOT violate Fedora Packaging Guidelines (we should strive to change them if needed).
  • Maintainers HAVE TO be able to step in for automation and replace some of its actions if needed. The automation NEEDS TO handle such situation.
  • Proven packagers and rel-eng still needs to be able to do their work in dist-git: their workflows MUST NOT be dirupted.

Goals

For start, we would love to focus on two areas:

Easier maintenance for rawhide

Updating packages in rawhide should only require changes in the packaging files and approving PRs.

Workflow
  1. Set up a source-git repository manually on a packit-supported platform (github.com, gitlab.com)
    • This includes creating a specific branch and setting up jobs for packit-service to handle events.
    • CI can (and should) be set up (such as Testing Farm).
  1. Anyone in the community is able to interact with this repository the same way with any other open-source project.
  1. Packit-service can accept events when a new upstream release is done (via Upstream Release Monitoring).
  1. Packit-service creates a pull request which contains changes to bring the new release to Rawhide.
    • A dist-git PR is created in parallel. Downstream checks are synchronized to the source-git PR.
  1. The owner of the source-git repository reviews and updates the pull request as needed.
  1. Once approved, dist-git PR is merged first and packit-service triggers a build in Rawhide. If the build passes, source-git PR is merged as well. If the build fails, source-git PR is updated a new dist-git PR is created and doing the cycle of this step again.


More convenient way to work on downstream patches

Downstream patches are tracked as git commits. This way it's easier to backport or cherry-pick changes from the upstream and rebase the patches when a new upstream release happens.

  • Commits can be picked up easily the same way as in any other git repo.
  • Patch file names can be configured.
  • Patches are automatically added to spec file.


MVP

The "product" of this SIG should be implementation of a following MVP. Once that's done, we'll evaluate what should be the next steps.

  • Source git repos can be easily created, set up and this is well-documented.
  • New upstream releases are automatically brought into the source-git repos when configured.
  • Changes pushed to source-git repos are automatically proposed downstream for inclusion in dist-git.


Members

Status

We have been in a planning stage of the SIG: bringing interested people together to flesh out the who, what, where, when, and how.

Communication

  • #packit on Freenode IRC
  • Mailing list - user-cont-team@redhat.com

Important links