(reshuffle, update comms, redefine mvp) |
mNo edit summary |
||
(24 intermediate revisions by 7 users not shown) | |||
Line 1: | Line 1: | ||
=== 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 | 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 | * 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. | |||
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 === | === 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 ( | # 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]] | ||
* 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 | 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 == | ||
* 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
- 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).
- 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 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
- Tomáš Tomeček
- František Lachman
- Jiri Popelka
- Stephen Coady
- Justin Forbes Fedora Kernel
- Matthew Almond (Representing Facebook)
🔗 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
- Issue tracker: https://pagure.io/fedora-source-git/sig/issues
- IRC channel: #fedora-source-git at LiberaChat or #packit at LiberaChat