PR#169: Add the answers to the remaining user stories - fedora-infra/arc

fedora-infra / arc

#169 Add the answers to the remaining user stories

Closed 8 months ago by t0xic0der. Opened 8 months ago by t0xic0der.

char into main

Make some formatting corrections

Akashdeep Dhar • 8 months ago

2802917

Add 9 more answers to user stories

Akashdeep Dhar • 8 months ago

e9e255c

Add 10 more answers to user stories

Akashdeep Dhar • 8 months ago

0ebeeca

Add 10 more answers to user stories

Akashdeep Dhar • 8 months ago

1a7c0ce

docs/dist-git-comparison/forgejo.rst

file modified

+31 -29

		`@@ -6,6 +6,8 @@`
		`User stories`
		`------------`

		`+ Following is the investigation on Forgejo based on the user stories collected.`
		`+`
		`1. As a package maintainer, I'd like to be able to run my own CI jobs on distgit PRs.`
		`While added as recently as 2023-02-27, Forgejo supports an integrated continuous integration system called Actions (https://forgejo.org/2023-02-27-forgejo-actions/). For specific purposes where a custom environment is required, even custom Forgejo runners (https://code.forgejo.org/forgejo/runner) can be associated with a certain project repository or project namespace.`

		`@@ -87,7 +89,7 @@`
		`Please check the answer to the user story #3.`

		`25. As a package maintainer, I'd like existing STI and TMT CI tests to continue working while also providing a simpler, more familiar YAML-based format.`
		`- As mentioned in cell F2, as long as the Forgejo Actions is configured properly to support STI and TMT CI tests, they should work fine on Forgejo like they do on Pagure - both in environments provided within the managed Forgejo infrastructure and in custom Forgejo runners introduced externally.`
		`+ As mentioned in the answer to the user story #1, as long as the Forgejo Actions is configured properly to support STI and TMT CI tests, they should work fine on Forgejo like they do on Pagure - both in environments provided within the managed Forgejo infrastructure and in custom Forgejo runners introduced externally.`

		`26. As a package maintainer, I want to be able to prevent direct push to git, and using merge requests process only.`
		`Please check the answer to the user story #3.`
		`@@ -171,88 +173,88 @@`
		`Please check the answer to the user story #7.`

		`51. As a consumer of the fedora messaging bus, I want to be able to continue to receive messages in a JSON format on events.`
		`- UNRESOLVED`
		`+ With the introduction of the Webhook To Fedora Messaging (https://github.com/fedora-infra/webhook-to-fedora-messaging/ project, webhooks (https://forgejo.org/docs/v1.19/user/webhooks/) on the platform can be integrated with the service to stay posted about the activities at the forge end.`

		`52. As a developer/release engineer/QA/contributor, we need the new dist-git service to have hooks to attach new and existing CI pipelines.`
		`- UNRESOLVED`
		`+ Forgejo supports webhooks (https://forgejo.org/docs/v1.19/user/webhooks/) so as long as we are able to leverage the features with our existing CI pipelines - the service should be able to function similarly to the existing Pagure based git forge.`

		`53. As a contributor, I need to be able to login using my Fedora account.`
		`- UNRESOLVED`
		+ Forgejo supports FreeIPA (https://forgejo.org/docs/v1.19/user/authentication/#freeipa) and hence, plugging in support for authentication using Fedora Account System account should be possible. This has been implemented to various degrees of success in the testing deployment (https://forgejoroute-communishift-forgejo.apps.fedora.cj14.p1.openshiftapps.com/) of Forgejo and hence, the same knowledge can be made use of in this implementation. This extends to group based access controls as well which means that Fedora Account System groups can be used to map access levels at the Forgejo end.

		`54. As a developer, I would like there to be a separate staging and production instance of dist-git so I can test my changes before pushing them.`
		`- UNRESOLVED`
		`+ Being a free and open source software, we should be able to deploy multiple instances of Forgejo with each instance having its own purpose and authentication backend without any issues.`

		`55. As a maintainer of dist-git(s), I would like to use industry-standard tools to maintain large files.`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #34.`

		`56. As a maintainer, I would like an easy-to-use interface to make suggestions on individual code blocks and suggest changes that the submitter can simply apply.`
		`- UNRESOLVED`
		`+ While I suggest rebasing and applying changes based on the review comments for a cleaner Git history, it is technically impossible (https://forgejo.org/docs/latest/user/pull-requests-and-git-flow/) for collaborators to apply the suggest changes with a click of a button on GitLab.`

		`57. As a package maintainer, I would like to be able to automatically transfer issues between packages (for example from ansible -> ansible-core).`
		`- UNRESOLVED`
		`+ This is unfortunately impossible in Forgejo and in order to pull off something like this, one would have to make use of their REST API (https://forgejo.org/docs/latest/user/api-usage/) to delete the issue ticket from the source namespace and create a new instance of it at the destination namespace.`

		`58. A package maintainer, I would like a push hook to block pushes to retired or EOL branches`
		`- UNRESOLVED`
		`+ While a relevant documentation could not be found on the matter, as Forgejo is based on Git version control system - it should be theoretically possible to conditionalize the rejection of a pushed commit whenever they are made against a branch that is slated to be retired or EOLed. The absence of a documentation means that more efforts has to be put into it.`

		`59. As a package maintainer, I want to be able to grant access to specific branches, or branches matching a pattern, to individual users. In pagure this is referred to as collaborator access.`
		`- UNRESOLVED`
		`+ It is possible to configure the access levels per branch dependent on certain branch names or branch names matching a certain pattern in Forgejo. The feature is called "Branch and tag protection (https://forgejo.org/docs/v1.19/user/protection/)".`

		`60. As a policy enforcer, I want to be able to "orphan" packages that are not mine.`
		`- UNRESOLVED`
		`+ Do you want to archive the source repository to signify the "orphaning" of a package? It is possible on Forgejo on all projects. Also, it has to be the owner of the repository (https://forgejo.org/docs/v1.19/user/repo-permissions/) who can archive a said repository.`

		`61. As a developer, I want to be query packages by their maintainers and vice versa.`
		`- UNRESOLVED`
		`+ Packages (or in this case, their representation as project repositories) have an ability of managing collaborators (https://docs.codeberg.org/collaborating/invite-collaborators/) associated with the project. Checking the packages associated with maintainers and checking maintainers associated with packages should be possible.`

		`62. As a packager, I need the new forge to support the orphaned packages process: a maintainer should be able to automatically orphan a package they own and another packager should be able to take ownership through a self-service interface.`
		`- UNRESOLVED`
		`+ Extending the answer to the user story #60, a workflow can established around the action of "archiving" a project repository - that in turn leads to automatically opening up an issue ticket that reports the "orphanment" (can we please use the word "abandonment" here?) of a package on a central issue tracker.`

		`63. As a package maintainer, I need the forge to allow me to push branches that do not share history with other branches.`
		`- UNRESOLVED`
		`+ This is a Git technicality as Forgejo is based on Git, this should be possible.`

		`64. As a driveby contributor, who is not a provenpackager (or does not want to use their provenpackager rights), I need to be able to open a Pull Request/Merge Request which introduces zero code changes (it has only empty commit(s) to bump the release for packages using %autorelease).`
		`- UNRESOLVED`
		`+ If by empty commits, minimal changes to the specfile is inferred - this should be possible by contributors as long as they have minimal access of being able to READ the said project repository. For more access, it is strongly advised for the contributor to be onboarded onto the process so that they can conveniently keep contributing.`

		65. As a proven packager, I want to be able to do basic repo operations from the command line. For example, I have the following in my history fedpkg fork && git remote rename zbyszek my && git push my rawhide:bin-sbin-merge, which I used maybe a hundred times when working on packages for the bin-sbin merge. I would then click on the link printed by the push command and review the diff before submitting a pull request and possibly adjust the commit message. Generalizing from this, all operations like forking, merging and closing of pull requests, should be possible via a command line tool. The tool must also be packaged in Fedora.
		`- UNRESOLVED`
		`+ Please check the answer to the user story #8.`

		`66. As a documentation contributor, I would love to try out new Git forge test systems. I'm agnostic to tools, so I believe I can spend time on UX and docs workflow (build, preview, issue tracking, GitHUb Action-like features and so on).`
		`- UNRESOLVED`
		`+ Forgejo's UX feels a lot more polished as compared to GitLab for those who are agnostic to tools. It is crucial to note that Forgejo has recently added accessibility (https://codeberg.org/forgejo/meta/pulls/179) as one of Forgejo project's values in an interest to develop a git forge with accessibility concerns.`

		`67. As a member of the CDT team I need to be able to get notified automatically when someone opens a design request. (An email will be sent to a mailing list).`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #3 and user story #12.`

		`68. As a member of release engineering, I need to be able to enforce that all repos in dist-git disallows the rewriting of history. (There's nuance here; it might be okay to allow rewriting on non-standard branches, but we'd need a way to confirm that none of the affected commits were ever used to perform an official build. This is probably more effort than it's worth vs simply disallowing rewriting on any branch)`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #23 and user story #32.`

		`69. As a packager/user, I'd like to be able to easily determine which commits were used in the creation of particular Fedora builds. A preferred mechanism for this would be to have hooks in place that can automatically commit git tags (signed with an official GPG signature) indicating associated NVRs.`
		`UNRESOLVED`

		`70. As a packager, I'd like to be able to use "draft builds" in merge requests that are then promoted to official builds when the MR is merged. This is to ensure that the build that was tested and approved in the MR is the same one that gets submitted as an erratum.`
		`- UNRESOLVED`
		`+ Using GitLab CI, the replacement git forge can be configured to kickoff mock builds whenever pull requests are created and actual builds whenever pushes are made against the primary branch of the repository. This should facilitate packagers to immediately head over to Bodhi to schedule a new release after a pull request was merged.`

		`71. As a packager, I'd like the option to have packages submitted as an erratum automatically when a merge request is merged. Ideally, this would be supplemental to the above "draft builds", just submitting that exact build to errata.`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #70.`

		`72. As a packager, I'd like to be able to provide my own test pipelines for merge requests on individual projects (supplemental to any standard tests provided and/or required by Fedora).`
		`- UNRESOLVED`
		`+ One can declare custom workflow configuration on Forgejo Actions (https://forgejo.org/docs/v1.20/user/actions/) in addition to the standard tests and builds (draft and actual) facilitated by Fedora Project. While still in alpha, self proposed Forgejo Runners (https://code.forgejo.org/forgejo/runner) is expected to be able to ensure that any testing that has sensitive information or requires specialized resources are addressed suitably - when it becomes production ready.`

		`73. As a member of Fedora Quality, I need to be able to transparently move any ticket opened by any user for one package to another package and preserve history.`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #57.`

		`74. As a member of Fedora Quality, I would like to be able to define ticket submission form templates with custom fields. And create input validations and query all opened tickets based on those field definitions.`
		`- UNRESOLVED`
		`+ Extending the answer to the user story #44 and user story #47, it is possible for Forgejo to implement templates for ticket submissions but cannot show already opened issue tickets with the similar verbiage to validate if the potential submission has already been proposed. The proposer needs to search for issue ticket by themselves before opening one.`

		`75. As a member of Fedora Quality, I need to be able to specify "need_info" on a specific ticket. This function should regularly ping (email/matrix or any other channels) the specified user that I am requesting information from.`
		`- UNRESOLVED`
		`+ It is recommended to use the assignee section of a certain issue ticket and/or to tag the people involved in the action using their username. While this might not facilitate pings to be made to a certain user at equal intervals of time, it can very well be used to keep them posted about the updates made to the issue ticket and to inform them about their action items.`

		`76. As a policy enforcer, I need to be able to get all the information about a ticket/issue/bug from a Python script in a structured way.`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #8 and user story #9.`

		`77. As a policy enforcer, I need to be able to open/modify/comment on a ticket/issue/bug from a Python script (including all the possible metadata).`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #8 and user story #9.`

		`78. As a policy designer, I need to be able to add custom and structured metadata to a ticket/issue/bug, in the form of key=value pairs. I need to be able to set rules for individual keys (such as which values are valid).`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #8 and user story #9.`

		`79. As a package maintainer, I want to have syntax highlighting for RPM spec files in the git forge web interface. Currently Pagure and Forgejo have this, but GitLab does not.`
		`- UNRESOLVED`
		`+ Good point! We can ask the GitLab folks nicely to add that I suppose.`

docs/dist-git-comparison/gitlab.rst

file modified

+28 -28

		`@@ -181,88 +181,88 @@`
		`Please check the answer to the user story #7.`

		`51. As a consumer of the fedora messaging bus, I want to be able to continue to receive messages in a JSON format on events.`
		`- UNRESOLVED`
		`+ With the introduction of the Webhook To Fedora Messaging (https://github.com/fedora-infra/webhook-to-fedora-messaging/) project, webhooks (https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) on the platform can be integrated with the service to stay posted about the activities at the forge end.`

		`52. As a developer/release engineer/QA/contributor, we need the new dist-git service to have hooks to attach new and existing CI pipelines.`
		`- UNRESOLVED`
		`+ GitLab supports webhooks (https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) so as long as we are able to leverage the features with our existing CI pipelines - the service should be able to function similarly to the existing Pagure based git forge.`

		`53. As a contributor, I need to be able to login using my Fedora account.`
		`- UNRESOLVED`
		+ GitLab supports SAML (https://docs.gitlab.com/ee/integration/saml.html) and hence, plugging in support for authentication using a Fedora Account System account should be possible. This has been implemented to various degrees of success in the fedora namespace of the GitLab.com offering and hence, the same knowledge can be made use of in this implementation. This extends to group based access controls as well which means that Fedora Account System groups can be used to map access levels at the GitLab end.

		`54. As a developer, I would like there to be a separate staging and production instance of dist-git so I can test my changes before pushing them.`
		`- UNRESOLVED`
		`+ Being a free and open source software, we should be able to deploy multiple instances of GitLab with each instance having its own purpose and authentication backend without any issues.`

		`55. As a maintainer of dist-git(s), I would like to use industry-standard tools to maintain large files.`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #34.`

		`56. As a maintainer, I would like an easy-to-use interface to make suggestions on individual code blocks and suggest changes that the submitter can simply apply.`
		`- UNRESOLVED`
		`+ While I suggest rebasing and applying changes based on the review comments for a cleaner Git history, it is technically possible (https://docs.gitlab.com/ee/user/project/merge_requests/reviews/) for collaborators to apply the suggest changes with a click of a button on GitLab.`

		`57. As a package maintainer, I would like to be able to automatically transfer issues between packages (for example from ansible -> ansible-core).`
		`- UNRESOLVED`
		`+ This is fortunately possible in GitLab in a feature (https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#bulk-move-issues), that is blissfully unrestricted across various tiers of subscription. The transfers work without the restriction of the repositories having to belong under the same namespace.`

		`58. A package maintainer, I would like a push hook to block pushes to retired or EOL branches`
		`- UNRESOLVED`
		`+ GitLab supports Git Server hooks (https://docs.gitlab.com/ee/administration/server_hooks.html) which can be used to conditionalize the rejection of a pushed commit whenever they are made against a branch that is slated to be retired or EOLed. The presence of a documentation should make the process relatively convenient.`

		`59. As a package maintainer, I want to be able to grant access to specific branches, or branches matching a pattern, to individual users. In pagure this is referred to as collaborator access.`
		`- UNRESOLVED`
		`+ It is possible to configure the access levels per branch dependent on certain branch names or branch names matching a certain pattern in GitLab. The feature is called "Protected Branches (https://docs.gitlab.com/ee/user/project/repository/branches/protected.html)" and is blissfully unrestricted across various tiers of subscription.`

		`60. As a policy enforcer, I want to be able to "orphan" packages that are not mine.`
		`- UNRESOLVED`
		`+ Do you want to archive the source repository to signify the "orphaning" of a package? It is possible (https://docs.gitlab.com/ee/user/project/working_with_projects.html#archive-a-project) on GitLab on all projects. Also, if a user has elevated privileges to a namespace (https://docs.gitlab.com/ee/user/permissions.html) under which the said repository exists - they can do it even though they do not own the said repository.`

		`61. As a developer, I want to be query packages by their maintainers and vice versa.`
		`- UNRESOLVED`
		`+ Packages (or in this case, their representation as project repositories) have an ability of managing members (https://docs.gitlab.com/ee/user/project/members/) associated with the project. Checking the packages associated with maintainers and checking maintainers associated with packages should be possible.`

		`62. As a packager, I need the new forge to support the orphaned packages process: a maintainer should be able to automatically orphan a package they own and another packager should be able to take ownership through a self-service interface.`
		`- UNRESOLVED`
		`+ Extending the answer to the user story #60, a workflow can established around the action of "archiving" a project repository - that in turn leads to automatically opening up an issue ticket that reports the "orphanment" (can we please use the word "abandonment" here?) of a package on a central issue tracker.`

		`63. As a package maintainer, I need the forge to allow me to push branches that do not share history with other branches.`
		`- UNRESOLVED`
		`+ This is a Git technicality and as GitLab is based on Git, this should be possible.`

		`64. As a driveby contributor, who is not a provenpackager (or does not want to use their provenpackager rights), I need to be able to open a Pull Request/Merge Request which introduces zero code changes (it has only empty commit(s) to bump the release for packages using %autorelease).`
		`- UNRESOLVED`
		`+ If by empty commits, minimal changes to the specfile is inferred - this should be possible by contributors as long as they have minimal access of being able to READ the said project repository. For more access, it is strongly advised for the contributor to be onboarded onto the process so that they can conveniently keep contributing.`

		65. As a proven packager, I want to be able to do basic repo operations from the command line. For example, I have the following in my history fedpkg fork && git remote rename zbyszek my && git push my rawhide:bin-sbin-merge, which I used maybe a hundred times when working on packages for the bin-sbin merge. I would then click on the link printed by the push command and review the diff before submitting a pull request and possibly adjust the commit message. Generalizing from this, all operations like forking, merging and closing of pull requests, should be possible via a command line tool. The tool must also be packaged in Fedora.
		`- UNRESOLVED`
		`+ Please check the answer to the user story #8.`

		`66. As a documentation contributor, I would love to try out new Git forge test systems. I'm agnostic to tools, so I believe I can spend time on UX and docs workflow (build, preview, issue tracking, GitHUb Action-like features and so on).`
		`- UNRESOLVED`
		`+ GitLab's UX feels a lot more polished as compared to Forgejo for those who are agnostic to tools. It is crucial to note that GitLab provides an accessible (https://docs.gitlab.com/ee/development/fe_guide/accessibility/) UX for the convenience of users using screen readers and keyboard-only functionality.`

		`67. As a member of the CDT team I need to be able to get notified automatically when someone opens a design request. (An email will be sent to a mailing list).`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #3 and user story #12.`

		`68. As a member of release engineering, I need to be able to enforce that all repos in dist-git disallows the rewriting of history. (There's nuance here; it might be okay to allow rewriting on non-standard branches, but we'd need a way to confirm that none of the affected commits were ever used to perform an official build. This is probably more effort than it's worth vs simply disallowing rewriting on any branch)`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #23 and user story #32.`

		`69. As a packager/user, I'd like to be able to easily determine which commits were used in the creation of particular Fedora builds. A preferred mechanism for this would be to have hooks in place that can automatically commit git tags (signed with an official GPG signature) indicating associated NVRs.`
		`UNRESOLVED`

		`70. As a packager, I'd like to be able to use "draft builds" in merge requests that are then promoted to official builds when the MR is merged. This is to ensure that the build that was tested and approved in the MR is the same one that gets submitted as an erratum.`
		`- UNRESOLVED`
		`+ Using GitLab CI, the replacement git forge can be configured to kickoff mock builds whenever pull requests are created and actual builds whenever pushes are made against the primary branch of the repository. This should facilitate packagers to immediately head over to Bodhi to schedule a new release after a pull request was merged.`

		`71. As a packager, I'd like the option to have packages submitted as an erratum automatically when a merge request is merged. Ideally, this would be supplemental to the above "draft builds", just submitting that exact build to errata.`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #70.`

		`72. As a packager, I'd like to be able to provide my own test pipelines for merge requests on individual projects (supplemental to any standard tests provided and/or required by Fedora).`
		`- UNRESOLVED`
		`+ One can declare custom workflow configuration on GitLab CI (https://docs.gitlab.com/ee/ci/) in addition to the standard tests and builds (draft and actual) facilitated by Fedora Project. Furthermore, self proposed GitLab Runners (https://docs.gitlab.com/runner/) can also be registered to a certain project to ensure that any testing that has sensitive information or requires specialized resources are addressed suitably.`

		`73. As a member of Fedora Quality, I need to be able to transparently move any ticket opened by any user for one package to another package and preserve history.`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #57.`

		`74. As a member of Fedora Quality, I would like to be able to define ticket submission form templates with custom fields. And create input validations and query all opened tickets based on those field definitions.`
		`- UNRESOLVED`
		`+ Extending the answer to the user story #44 and user story #47, it is possible for GitLab to implement templates for ticket submissions and show already opened issue tickets with the similar verbiage to validate if the potential submission has already been proposed. The proposer needs not search for issue ticket by themselves before opening one.`

		`75. As a member of Fedora Quality, I need to be able to specify "need_info" on a specific ticket. This function should regularly ping (email/matrix or any other channels) the specified user that I am requesting information from.`
		`- UNRESOLVED`
		`+ It is recommended to use the assignee section of a certain issue ticket and/or to tag the people involved in the action using their username. While this might not facilitate pings to be made to a certain user at equal intervals of time, it can very well be used to keep them posted about the updates made to the issue ticket and to inform them about their action items.`

		`76. As a policy enforcer, I need to be able to get all the information about a ticket/issue/bug from a Python script in a structured way.`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #8 and user story #9.`

		`77. As a policy enforcer, I need to be able to open/modify/comment on a ticket/issue/bug from a Python script (including all the possible metadata).`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #8 and user story #9.`

		`78. As a policy designer, I need to be able to add custom and structured metadata to a ticket/issue/bug, in the form of key=value pairs. I need to be able to set rules for individual keys (such as which values are valid).`
		`- UNRESOLVED`
		`+ Please check the answer to the user story #8 and user story #9.`

		`79. As a package maintainer, I want to have syntax highlighting for RPM spec files in the git forge web interface. Currently Pagure and Forgejo have this, but GitLab does not.`
		`- UNRESOLVED`
		`+ Good point! We can ask the GitLab folks nicely to add that I suppose.`

docs/dist-git-comparison/stories.rst

file modified

+50 -50

		`@@ -9,154 +9,154 @@`
		`Following is the investigation on GitLab based on the user stories collected.`

		`1. As a package maintainer, I'd like to be able to run my own CI jobs on distgit PRs.`
		- ``Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906653>`_ <>`_ Maxwell G (``gotmax23``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906653>`_ by Maxwell G (``gotmax23``)

		`2. As a package maintainer, I'd like to be able to control the-new-hotness monitoring status from distgit.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906654>`_ Maxwell G (``gotmax23``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906654>`_ by Maxwell G (``gotmax23``)

		`3. As a provenpackager, I should have push and merge access to all packages in the Fedora package collection.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906655>`_ Maxwell G (``gotmax23``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906655>`_ by Maxwell G (``gotmax23``)

		`4. As a package maintainer and Fedora tooling maintainer, I'd like to be able to use Packit in both distgit and upstream repositories.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906656>`_ Maxwell G (``gotmax23``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906656>`_ by Maxwell G (``gotmax23``)

		`5. As a package maintainer, I'd like to have easy access links to Koji, Bodhi, and Koschei from the distgit repo.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906657>`_ Maxwell G (``gotmax23``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906657>`_ by Maxwell G (``gotmax23``)

		`6. As a packager sponsor/mentor, I'd like to help users from outside the packager make their first PR without requiring special tooling or authentication schemes.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906658>`_ Maxwell G (``gotmax23``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906658>`_ by Maxwell G (``gotmax23``)

		`7. As a package maintainer and tooling maintainer, I'd like to be able to set Depends-on: and Blocks: relationships between tickets in the issue tracker.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906660>`_ Maxwell G (``gotmax23``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906660>`_ by Maxwell G (``gotmax23``)

		`8. As a package maintainer, I'd like to continue to be able to use fedpkg to fork repositories and otherwise interact with distgit.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906661>`_ Maxwell G (``gotmax23``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-906661>`_ by Maxwell G (``gotmax23``)

		`9. As a package maintainer, I want to be able to control all aspects of the pull request process (read comments, reply to comments, approve PRs, merge PRs, etc) via an REST API to allow creation command line tools to automate work that otherwise requires a pointy-clicky web UI.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908622>`_ Daniel P. Berrange (``berrange``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908622>`_ by Daniel P. Berrange (``berrange``)

		`10. As a package maintainer, I want to be able to mark a PR to automatically merge if-and-only-if a running CI pipeline has succeeded. This allows reviewing and approving a PR, and moving onto new work, without having to wait around to see if CI passes or not. The PR only needs re-visiting manually if CI failed.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908623>`_ Daniel P. Berrange (``berrange``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908623>`_ by Daniel P. Berrange (``berrange``)

		`11. As a contributor, I want to be able to see who the current maintainer(s) are for a package.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908624>`_ Daniel P. Berrange (``berrange``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908624>`_ by Daniel P. Berrange (``berrange``)

		`12. As a contributor, I want to be able to request to join the maintainer(s) for a package, either as a watcher (just notified of all PRs), or as a developer (participate in MR process), or as a maintainer (control all aspects of the package, ie user ACLs). Joining as merely a watcher should not require approval by current maintainers.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908626>`_ Daniel P. Berrange (``berrange``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908626>`_ by Daniel P. Berrange (``berrange``)

		`13. As a package maintainer, I want opening a MR to automatically create a scratch-build. Approving the MR, should be able to either automatically promote the scratch-build to non-scratch status, or create a new non-scratch build. The latter should have a way to disable for packages with huge build times where creation of one build for multiple approved MRs is desirable for efficiency.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908627>`_ Daniel P. Berrange (``berrange``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908627>`_ by Daniel P. Berrange (``berrange``)

		`14. As a package maintainer, I would like to see the dependencies of this package, and what packages that are required by this package on web UI.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908634>`_ Felix Wang (``topazus``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908634>`_ by Felix Wang (``topazus``)

		`15. As a contributor, I want to be able to see who the current maintainer(s) are for a package.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908648>`_ Fernando Dos Santos (``ferox``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908648>`_ by Fernando Dos Santos (``ferox``)

		`16. As a contributor, I want to be able to see the contributors that have contributed to this package.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908660>`_ Felix Wang (``topazus``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908660>`_ by Felix Wang (``topazus``)

		`17. "As a packager I want to be able to have commit access without being added to the bugzilla watch list.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908765>`_ Pierre-Yves Chibon (``pingou``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908765>`_ by Pierre-Yves Chibon (``pingou``)

		`18. As a community member I want the ability to be added to the bugzilla watch list for a package without having commits or being in the packager group.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908766>`_ Pierre-Yves Chibon (``pingou``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908766>`_ by Pierre-Yves Chibon (``pingou``)

		`19. As a Fedora Infrastructure member, I want to ensure people who sign in to watch a package on bugzilla have a valid bugzilla account associated with their FAS account.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908767>`_ Pierre-Yves Chibon (``pingou``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908767>`_ by Pierre-Yves Chibon (``pingou``)

		`20. As a user of Fedora, not necessarily a member of the Fedora Project, I want to receive information about Fedora packages in the form of readable HTML documents, not in the form of programs (in Javascript or Web Assembly) that I must execute before I get to see the information.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908906>`_ Bjorn Persson (``romboberorn``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908906>`_ by Bjorn Persson (``romboberorn``)

		`21. As a security-conscious packager, I want to interact with the web interface without downloading and running programs from a bunch of third parties. I should at most need to whitelist Javascript and Web Assembly from fedoraproject.org only.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908907>`_ Bjorn Persson (``romboberorn``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908907>`_ by Bjorn Persson (``romboberorn``)

		`22. As a member of the Free Software movement, I want all parts of the system to be Free Software. That includes both server-side software and all Javascript, Web Assembly and/or CSS that my browser will download and execute.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908908>`_ Bjorn Persson (``romboberorn``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-908908>`_ by Bjorn Persson (``romboberorn``)

		`23. As a package maintainer, I want to be able to use a pull-request-only workflow for specific packages (like packages that could break a lot of things, or packages that are security sensitive).`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-911774>`_ Fabio Valentini (``decathorpe``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-911774>`_ by Fabio Valentini (``decathorpe``)

		`24. As a package maintainer with provenpackager or scm-admin rights, I want to be able to circumvent pull-request-only requirements on packages when pushing changes (i.e. mass rebuilds).`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-911775>`_ Fabio Valentini (``decathorpe``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-911775>`_ by Fabio Valentini (``decathorpe``)

		`25. As a package maintainer, I'd like existing STI and TMT CI tests to continue working while also providing a simpler, more familiar YAML-based format.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-911898>`_ Daniel P. Berrange (``berrange``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-911898>`_ by Daniel P. Berrange (``berrange``)

		`26. As a package maintainer, I want to be able to prevent direct push to git, and using merge requests process only.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914167>`_ Robert-Andre Mauchin (``eclipseo``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914167>`_ by Robert-Andre Mauchin (``eclipseo``)

		`27. As a package maintainer, I want to be able to deal with bugs directly from the forge, and be able to reassign them between projects.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914168>`_ Robert-Andre Mauchin (``eclipseo``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914168>`_ by Robert-Andre Mauchin (``eclipseo``)

		`28. As a package maintainer, I want to be able to sync a fork with the upstream with a button click.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914169>`_ Robert-Andre Mauchin (``eclipseo``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914169>`_ by Robert-Andre Mauchin (``eclipseo``)

		`29. As a package maintainer, I wish we had CI compatible with Github Actions.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914170>`_ Robert-Andre Mauchin (``eclipseo``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914170>`_ by Robert-Andre Mauchin (``eclipseo``)

		`30. As a contributor, I'd like to be able to interact with git and distgit via email, namely to reply to issue and PR comments.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914178>`_ Maxwell G (``gotmax23``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914178>`_ by Maxwell G (``gotmax23``)

		`31. A contributor, I'd like to be able to create repositories under a personal namespace for work related to Fedora.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914179>`_ Maxwell G (``gotmax23``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914179>`_ by Maxwell G (``gotmax23``)

		`32. As a package maintainer, I'd like to block branch creation outside of official ones, or remove branches outside of official ones.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914183>`_ Robert-Andre Mauchin (``eclipseo``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914183>`_ by Robert-Andre Mauchin (``eclipseo``)

		`33. As a contributor, I'd like the forge to be accessible (alt text for images, respecting whatwg standards for contrast, color blindness, aria support).`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914184>`_ Robert-Andre Mauchin (``eclipseo``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914184>`_ by Robert-Andre Mauchin (``eclipseo``)

		`34. As a package maintainer I'd like to be able to delete a wrong file from the look aside cache.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914185>`_ Robert-Andre Mauchin (``eclipseo``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914185>`_ by Robert-Andre Mauchin (``eclipseo``)

		`35. As a package maintainer, I'd wish to be able to see a tree of the Depends-on and Blocks bugs relationship, and export it to JSON or any easily processable document.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914256>`_ Robert-Andre Mauchin (``eclipseo``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914256>`_ by Robert-Andre Mauchin (``eclipseo``)

		`36. As a package maintainer, I wish to have a Security tab listing known CVE, and dependencies known CVE for the package.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914258>`_ Robert-Andre Mauchin (``eclipseo``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914258>`_ by Robert-Andre Mauchin (``eclipseo``)

		`37. As a package maintainer, I still want to be able to use Grokmirror to mirror the Forge packages locally.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914268>`_ Robert-Andre Mauchin (``eclipseo``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-914268>`_ by Robert-Andre Mauchin (``eclipseo``)

		`38. As an engineer involved in the release process, I want to be able to track blocker bugs and freeze exception bugs in the chosen issue tracker.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918157>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918157>`_ by Akashdeep Dhar (``t0xic0der``)

		`39. As an engineer involved in the release process, I want to be able to properly triage the state of the blocker bugs and freeze exception bugs with Kanban boards.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918158>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918158>`_ by Akashdeep Dhar (``t0xic0der``)

		`40. As an engineer involved in the release process, I should be able to notify the affected package maintainers and package testers.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918159>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918159>`_ by Akashdeep Dhar (``t0xic0der``)

		`41. As an engineer involved in the release process, I want to be able to plan for the effects on release phases (Alpha, Beta, Final) using the Gantt chart.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918160>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918160>`_ by Akashdeep Dhar (``t0xic0der``)

		`42. As an engineer involved in the release process, I want to be able to control the automated building and testing using comments.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918161>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918161>`_ by Akashdeep Dhar (``t0xic0der``)

		`43. As an engineer involved in the release process, I want to be able to triage the priorities of the blocker bugs and freeze exception bugs in the chosen issue tracker.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918162>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918162>`_ by Akashdeep Dhar (``t0xic0der``)

		`44. As an engineer involved in the release process, I want to be able to speed up the creation of blocker bugs and freeze exception bugs with the use of issue ticket templates.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918163>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918163>`_ by Akashdeep Dhar (``t0xic0der``)

		`45. As an engineer involved in the release process, I want to be able to limit the access of ticket modification to a certain set of people.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918164>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918164>`_ by Akashdeep Dhar (``t0xic0der``)

		`46. As an engineer involved in the release process, I want to be able to access the chosen issue tracker with the use of an HTTP API.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918165>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918165>`_ by Akashdeep Dhar (``t0xic0der``)

		`47. As an engineer involved in the release process, I want to be able to show related issue tickets to the reporter to avoid repeated rejections.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918166>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918166>`_ by Akashdeep Dhar (``t0xic0der``)

		`48. As an engineer involved in the release process, I want to be able to use the already established Bug Status Workflow as closely as possible.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918167>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918167>`_ by Akashdeep Dhar (``t0xic0der``)

		`49. As an engineer involved in the release process, I want to be able to automate ticketing workflows according to the phases of a release.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918168>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918168>`_ by Akashdeep Dhar (``t0xic0der``)

		`50. As an engineer involved in the release process, I want to be able to track accepted previous release blocker bugs in the chosen issue tracker.`
		- `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918170>`_ Akashdeep Dhar (``t0xic0der``)
		+ `Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-918170>`_ by Akashdeep Dhar (``t0xic0der``)

		`51. As a consumer of the fedora messaging bus, I want to be able to continue to receive messages in a JSON format on events.`
		`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-922472>`_ by Aoife Moloney (``amoloney``)