From Fedora Project Wiki
(hint MVP, add simple workflow)
mNo edit summary
 
(27 intermediate revisions by 7 users not shown)
Line 1: Line 1:
== Mission ==


'''This SIG is a work in progress and will be announced properly once we're ready, stay tuned.'''
=== Rules ===
 
* Whatever we produce here, it '''MUST NOT''' violate Fedora Packaging Guidelines (we should strive to change them if needed).
* Proven packagers and rel-eng still needs to be able to do their work in dist-git: their workflows MUST NOT be dirupted.
* 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.
 
=== Goals ===


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]].
Our main goal is build a Minimal Viable Product during the Fedora 36 development cycle.


=== Rules ===
==== MVP ====
 
* Source git repos can be easily created, set up and this process is well-documented.
 
* The workflow is defined well and it's clear where the repositories are hosted.
 
* Source-git content is proposed into dist-git via dist-git pull requests.
 
* Specfile changes are synchronized back to the source-git repo from dist-git.
 
==== Benefits to Fedora ====
 
* 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.
 
* Patch files are handled by automation which makes the job of maintainers easier.


* Whatever we produce here, it MUST NOT violate Fedora Packaging Guidelines (we should strive to change them if needed).
* It should be easier to onboard more maintainers in Fedora community since the workflow would be closer to the way the contributors work in the upstream project.
* Maintainers HAVE TO be able to step in for automation and replace some of its actions if needed.
* 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.


=== Goals ===
=== Meetings ===


For start, we would love to focus on two areas:
We have meetings every 4 weeks on Wednesday, 14:30 (2:30pm) UTC on Google Meet.


==== Easier maintenance for rawhide ====
https://apps.fedoraproject.org/calendar/SIGs/2021/5/3/#m9975


Updating "simple" packages in rawhide should be as easy as merging a PR in dist-git if all tests and checks pass.
==== Meeting minutes ====


===== Workflow =====
The meeting is scheduled for Thu, April 22nd: https://apps.fedoraproject.org/calendar/SIGs/2021/4/22/#m9966


1. Set up a source-git repository manually on a packit-supported platform (github.com, gitlab.com)
* 1st meeting (IRC): https://meetbot.fedoraproject.org/packit/2021-04-22/source-git-sig.2021-04-22-13.01.html
  * This includes creating a specific branch and setting up jobs for packit-service to handle events.
* 2nd meeting (gmeet): https://pagure.io/fedora-source-git/sig/blob/main/f/meeting-minutes/2020-05-05.md
  * CI is set up (such as [https://packit.dev/docs/testing-farm/ Testing Farm]).
* 3rd meeting (gmeet): https://pagure.io/fedora-source-git/sig/blob/main/f/meeting-minutes/2021-05-12.md
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]).
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.
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.


==== More convenient way to work on downstream patches ====
We have stopped doing meeting notes. We instead update tickets in our SIG issue tracker.


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.
=== Follow-up work ===


Once the MVP is implemented, we can start building a more automated workflow on top of the MVP.


==== MVP ====
===== Workflow =====


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.
# Set up a source-git repository manually on a packit-supported platform (gitlab.com, pagure.io (TBD))
#* 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 [https://packit.dev/docs/testing-farm/ Testing Farm]).
# Anyone in the community is able to interact with this repository the same way with any other open-source project.
# Packit-service can accept events when a new upstream release is done (via [https://release-monitoring.org/ Upstream Release Monitoring]).
# 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.


== Members ==
== Members ==
* [[User:Ttomecek|Tomáš Tomeček]]
* [[User:Ttomecek|Tomáš Tomeček]]
* Hunor Csomortáni
* František Lachman
* František Lachman
* [[User:Jpopelka|Jiri Popelka]]
* [[User:Jpopelka|Jiri Popelka]]
* [[User:scoady|Stephen Coady]]
* [[User:jforbes|Justin Forbes]] Fedora Kernel
* Matthew Almond (Representing Facebook)


== Status ==
== 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.
The SIG is now announced on the devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ITHR2QMNH3NXICI56JNBSVXWLKREXCN6/
 
We are looking for early adopters of the workflow and members to give us feedback during the development.


== Communication ==
== Communication ==
* #packit on Freenode IRC
 
* Mailing list - user-cont-team@redhat.com
* Issue tracker: https://pagure.io/fedora-source-git/sig/issues
* IRC channel: #fedora-source-git at [https://libera.chat/ LiberaChat] or #packit at [https://libera.chat/ LiberaChat]


== Important links ==
== Important links ==


* [https://packit.dev/docs/source-git Source-git]
* [https://packit.dev/docs/source-git Source-git]
[[Category:SIGs]]
[[Category:Fedora special-interest groups]]

Latest revision as of 09:04, 23 May 2023

Rules

  • Whatever we produce here, it MUST NOT violate Fedora Packaging Guidelines (we should strive to change them if needed).
  • Proven packagers and rel-eng still needs to be able to do their work in dist-git: their workflows MUST NOT be dirupted.
  • 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.

Goals

Our main goal is build a Minimal Viable Product during the Fedora 36 development cycle.

MVP

  • Source git repos can be easily created, set up and this process is well-documented.
  • The workflow is defined well and it's clear where the repositories are hosted.
  • Source-git content is proposed into dist-git via dist-git pull requests.
  • Specfile changes are synchronized back to the source-git repo from dist-git.

Benefits to Fedora

  • 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.
  • Patch files are handled by automation which makes the job of maintainers easier.
  • It should be easier to onboard more maintainers in Fedora community since the workflow would be closer to the way the contributors work in the upstream project.

Meetings

We have meetings every 4 weeks on Wednesday, 14:30 (2:30pm) UTC on Google Meet.

https://apps.fedoraproject.org/calendar/SIGs/2021/5/3/#m9975

Meeting minutes

The meeting is scheduled for Thu, April 22nd: https://apps.fedoraproject.org/calendar/SIGs/2021/4/22/#m9966

* 1st meeting (IRC): https://meetbot.fedoraproject.org/packit/2021-04-22/source-git-sig.2021-04-22-13.01.html
* 2nd meeting (gmeet): https://pagure.io/fedora-source-git/sig/blob/main/f/meeting-minutes/2020-05-05.md
* 3rd meeting (gmeet): https://pagure.io/fedora-source-git/sig/blob/main/f/meeting-minutes/2021-05-12.md

We have stopped doing meeting notes. We instead update tickets in our SIG issue tracker.

Follow-up work

Once the MVP is implemented, we can start building a more automated workflow on top of the MVP.

Workflow
  1. Set up a source-git repository manually on a packit-supported platform (gitlab.com, pagure.io (TBD))
    • 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).
  2. Anyone in the community is able to interact with this repository the same way with any other open-source project.
  3. Packit-service can accept events when a new upstream release is done (via Upstream Release Monitoring).
  4. 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.
  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 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.

Members

Status

The SIG is now announced on the devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ITHR2QMNH3NXICI56JNBSVXWLKREXCN6/

We are looking for early adopters of the workflow and members to give us feedback during the development.

Communication

Important links