From 1a7c0cea77431755e3a0d493bbb8df1947253988 Mon Sep 17 00:00:00 2001 From: Akashdeep Dhar Date: Sep 16 2024 09:35:47 +0000 Subject: Add 10 more answers to user stories Signed-off-by: Akashdeep Dhar --- diff --git a/docs/dist-git-comparison/forgejo.rst b/docs/dist-git-comparison/forgejo.rst index 3648f10..17f8c6f 100644 --- a/docs/dist-git-comparison/forgejo.rst +++ b/docs/dist-git-comparison/forgejo.rst @@ -171,34 +171,34 @@ User stories 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 `_ project, `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 `_ 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 `_ 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 `_ 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 `_ 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 `_ 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 `_". 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 `_ who can archive a said repository. 61. **As a developer, I want to be query packages by their maintainers and vice versa.** UNRESOLVED diff --git a/docs/dist-git-comparison/gitlab.rst b/docs/dist-git-comparison/gitlab.rst index 9357f78..e9c0cad 100644 --- a/docs/dist-git-comparison/gitlab.rst +++ b/docs/dist-git-comparison/gitlab.rst @@ -181,34 +181,34 @@ Following is the investigation on GitLab based on the user stories collected. 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 `_ project, `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 + GitLab supports `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 + GitLab supports `SAML `_ 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 `_ 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 `_, 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 `_ 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 `_" 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 `_ on GitLab on all projects. Also, if a user has elevated privileges to a `namespace `_ 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