From Fedora Project Wiki
(reshuffle, update comms, redefine mvp)
mNo edit summary
 
(24 intermediate revisions by 7 users not shown)
Line 1: Line 1:
'''This SIG is a work in progress and will be announced properly once we're ready, stay tuned.'''


=== Rules ===
=== Rules ===
Line 8: Line 5:
* Proven packagers and rel-eng still needs to be able to do their work in dist-git: their workflows MUST NOT be dirupted.
* 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.
* 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 ===
=== Goals ===


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


==== MVP ====
==== MVP ====


* Source git repos can be easily created, set up and this is well-documented.
* 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.
* The workflow is defined well and it's clear where the repositories are hosted.


* Source-git content is synchronized into dist-git via dist-git pull requests.
* 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.
* Specfile changes are synchronized back to the source-git repo from dist-git.


==== Benefits to Fedora ====
==== Benefits to Fedora ====
Line 33: Line 28:
* 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.
* 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.


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


TBD
==== Meeting minutes ====


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


* Agree on communication channels
* 1st meeting (IRC): https://meetbot.fedoraproject.org/packit/2021-04-22/source-git-sig.2021-04-22-13.01.html
* Define how work is going to be tracked
* 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 ===
=== Follow-up work ===


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


===== Workflow =====
===== Workflow =====


# 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 (gitlab.com, pagure.io (TBD))
#* 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 can (and should) be 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]).
Line 60: Line 59:
# The owner of the source-git repository reviews and updates the pull request as needed.
# 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.
# 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 ==


TBD - will be defined during our first meeting.
* 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]
In the meantime you can reach out to the team on #packit at Freenode IRC.


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