Apply suggestions from code review

Co-authored-by: Laura Barcziová <49026743+lbarcziova@users.noreply.github.com>

posts/flock_2024_diary/index.md

@@ -25,9 +25,9 @@ The requirement to have a git repository representing is now gone. By NOT specif
 
 If you are interested in having a nice git tree, you’ll welcome that the Packit team is currently working on making it possible t[o avoid diverging branches when doing release syncing](https://github.com/packit/packit-service/pull/2478).
 
-Another long-time-awaited feature is support for releasing package groups using side-tags. Since Flock, Nikola from the Packit team polished the functionality and even created a [dedicated documentation pag](https://packit.dev/docs/fedora-releases-guide/releasing-multiple-packages)e describing how to use it.
+Another long-time-awaited feature is support for releasing package groups using side-tags. Since Flock, Nikola from the Packit team polished the functionality and even created a [dedicated documentation page](https://packit.dev/docs/fedora-releases-guide/releasing-multiple-packages)e describing how to use it.
 
-And that’s not all, there are also two related efforts we are in the early phases. One is about using Packit to run reverse-dependency checks/builds. The update is that Mikolaj Izdebski (thanks a lot\!) re-enabled a Copr plugin in Koschei so it should now be possible to run the checks independently to Koji which is better for ad-hock CI checks but also to not produce extra load on Koji itself. Ideally, this would be available both in upstream and dist-git pull requests. And speaking of the dist-git pull requests, there is a discussion about [the future of Fedora CI](https://pagure.io/fedora-ci/general/issue/476) and Zuul, we agreed within a team to take a look and see if we can’t help with that. The reasons and questions to answer are covered in the talk.
+And that’s not all, there are also two related efforts we are in the early phases. One is about using Packit to run reverse-dependency checks/builds. The update is that Mikolaj Izdebski (thanks a lot\!) re-enabled a Copr plugin in Koschei so it should now be possible to run the checks independently to Koji which is better for ad-hock CI checks but also to not produce extra load on Koji itself. Ideally, this would be available for both upstream and dist-git pull requests. And speaking of the dist-git pull requests, there is a discussion about [the future of Fedora CI](https://pagure.io/fedora-ci/general/issue/476) and Zuul, we agreed within a team to take a look and see if we can’t help with that. The reasons and questions to answer are covered in the talk.
 
 And that’s still not all. There is also a Google Summer of Code project by Bryan Elee as part of which an integration for OpenBuildService is being implemented. Stay tuned. The CLI support is nearly there.
 
@@ -47,7 +47,7 @@ Also, Jan showed how you can newly generate your own Testing Farm tokens using y
 
 # Other talks and activities
 
-During the Flock, we’ve quite intensively discussed the possibility of running Packit in Fedora infrastructure. Why? Currently, Packit is run on a RedHat-hosted OpenShift instance, but Packit’s main target is Fedora and we don’t communicate (and also don’t want to) with Red Hat internal services. Also, to show clearly the users that Packit is part of Fedora. On this topic, there was a [talk](https://cfp.fedoraproject.org/flock-2024/talk/VL7D3H/) held by David Kirwan about Communishift which is here for users to deploy their projects on Fedora-hosted OpenShift. We can use it, but we discussed with CPE team, that OpenShift managed by CPE team and used for other Fedora infrastructure systems might be a better fit. Matěj Focko from our team collected our requirements and we were asked to communicate this publicly via [https://discussion.fedoraproject.org](https://discussion.fedoraproject.org/).
+During the Flock, we’ve quite intensively discussed the possibility of running Packit in Fedora infrastructure. Why? Currently, Packit is run on a RedHat-hosted OpenShift instance, but Packit’s main target is Fedora and we don’t communicate (and also don’t want to) with Red Hat internal services. Also, to show clearly the users that Packit is part of Fedora. On this topic, there was a [talk](https://cfp.fedoraproject.org/flock-2024/talk/VL7D3H/) held by David Kirwan about Communishift which is here for users to deploy their projects on Fedora-hosted OpenShift. We can use it, but we discussed with CPE team, that OpenShift managed by CPE team and used for other Fedora infrastructure systems might be a better fit. Matej Focko from our team collected our requirements and we were asked to communicate this publicly via [https://discussion.fedoraproject.org](https://discussion.fedoraproject.org/).
 
 A lot of interest was caught by the talk about Fedora dist-git forge replacement. [Tomas Hrcka](mailto:thrcka@redhat.com) quite nicely covered the current state that his team was asked to do the technical research but did not make any decision. Packit has even been included in their research which we are thankful for. Currently, we have two candidates – [Forgejo](https://forgejo.org/) and GitLab. Both have been deployed for testing purposes and can be accessed via Fedora staging accounts. So far, the Forgejo seems like a better choice both because of extensibility and ease of deployment/maintenance but nothing has been decided yet. There are two Packit-related topics – if Forgejo is picked, we need to implement its support in ogr, our library for git-forge communication, but hopefully, this would be the only place for change, let’s see…;) Another interesting thing is that there is an idea to provide dist-git functionality not directly on the git-forge, but as a separate dashboard/page and this might be worth collaborating as part of the project Myccorhisa.