From b1aa1ba086bb7ee84a37e190e2bf175da61e166c Mon Sep 17 00:00:00 2001 From: Akashdeep Dhar Date: Tue, 1 Oct 2024 14:15:15 +0530 Subject: [PATCH] Change user stories #27, #31, #57, #60, #62 and #78 Signed-off-by: Akashdeep Dhar --- docs/dist-git-comparison/forgejo.rst | 47 +++++++++++++++------------- docs/dist-git-comparison/gitlab.rst | 47 +++++++++++++++------------- 2 files changed, 51 insertions(+), 43 deletions(-) diff --git a/docs/dist-git-comparison/forgejo.rst b/docs/dist-git-comparison/forgejo.rst index d8775dc..926758d 100644 --- a/docs/dist-git-comparison/forgejo.rst +++ b/docs/dist-git-comparison/forgejo.rst @@ -185,11 +185,11 @@ Following is the investigation on Forgejo based on the user stories collected. Please check the answer to the user story #3. 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.** - Forgejo provides with the functionality of creating - organizations (https://forgejo.org/docs/latest/user/linked-references/) that can have either - project repositories associated with them. As long as the issue tickets are created for the - project repository in a certain organization, they can be reassigned with other project - repositories belonging to the same organization. + 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 close or delete the issue ticket + from the source namespace and create a new instance of it at the destination namespace, and + point to the issue ticket at the source namespace if closed in the comments. 28. **As a package maintainer, I want to be able to sync a fork with the upstream with a button click.** While the operation of synchronizing the fork with the more recent changes in the upstream @@ -212,7 +212,9 @@ Following is the investigation on Forgejo based on the user stories collected. - establishing a two-way communication medium. 31. **A contributor, I'd like to be able to create repositories under a personal namespace for work related to Fedora.** - Please check the answer to the user story #27. + Every user associated with the Forgejo deployment should have a personal namespace associated + where they can create their repositories and store the repositories forked from somewhere + else on the same deployment. 32. **As a package maintainer, I'd like to block branch creation outside of official ones, or remove branches outside of official ones.** Please check the answer to the user story #23. @@ -349,11 +351,7 @@ Following is the investigation on Forgejo based on the user stories collected. collaborators to apply the suggest changes with a click of a button on Forgejo. 57. **As a package maintainer, I would like to be able to automatically transfer issues between packages (for example from ansible -> ansible-core).** - 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 close or delete the issue ticket - from the source namespace and create a new instance of it at the destination namespace, and - point to the issue ticket at the source namespace if closed in the comments. + Please check the answer to the user story #27. 58. **A package maintainer, I would like a push hook to block pushes to retired or EOL branches** While a relevant documentation could not be found on the matter, as Forgejo is based on Git @@ -367,10 +365,13 @@ Following is the investigation on Forgejo based on the user stories collected. 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.** - 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. + The homepage of the said package (consisting of ``README.md`` file) can be updated to + reflect the changed status of the package and the name of the package can be added to a list + where potential packagers can pick it up from. While there is no 1:1 support in the feature + parity, we can have an issue tracker where people can request the orphanment of the packages + that they own and an automated script can be run that removes their access + (https://forgejo.org/docs/v1.19/user/repo-permissions/) from the said package repository and + makes the status reflecting changes. 61. **As a developer, I want to be query packages by their maintainers and vice versa.** Packages (or in this case, their representation as project repositories) have an ability of @@ -380,9 +381,9 @@ Following is the investigation on Forgejo based on the user stories collected. 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.** Extending the answer to the user story #60, a workflow can be 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. + of requesting a package orphanment to an issue tracker - that in turn should kick off some + automation that ends up changing the project's homepage to reflect the status and enlisting + the package for potential packagers to "adopt". 63. **As a package maintainer, I need the forge to allow me to push branches that do not share history with other branches.** This is a Git technicality and as Forgejo is based on Git, this should be possible. @@ -397,7 +398,7 @@ Following is the investigation on Forgejo based on the user stories collected. 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).** - Forgejo's UX feels a lot more polished as compared to GitLab for those who are agnostic to + Forgejo's UX feels a lot less 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. @@ -435,7 +436,7 @@ Following is the investigation on Forgejo based on the user stories collected. 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.** - Please check the answer to the user story #57. + Please check the answer to the user story #27. 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.** Extending the answer to the user story #44 and user story #47, it is possible for Forgejo to @@ -457,7 +458,11 @@ Following is the investigation on Forgejo based on the user stories collected. 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).** - Please check the answer to the user story #8 and user story #9. + While Forgejo provides a custom set of fields to be set for the issue tickets, those fields + are not as customizable as they are in Bugzilla. As a result, if this is a requirement people + will have to rely on the issue + templates (https://forgejo.org/docs/latest/user/issue-pull-request-templates/) to fill in + custom information. 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.** Forgejo already supports the highlighting for RPM spec files. diff --git a/docs/dist-git-comparison/gitlab.rst b/docs/dist-git-comparison/gitlab.rst index 2aa0644..3f46abd 100644 --- a/docs/dist-git-comparison/gitlab.rst +++ b/docs/dist-git-comparison/gitlab.rst @@ -201,12 +201,10 @@ Following is the investigation on GitLab based on the user stories collected. Please check the answer to the user story #23. 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.** - GitLab provides with the functionality of creating - namespaces (https://docs.gitlab.com/ee/user/namespace/) that can have either multiple - namespaces or project repositories associated with them. As long as the issue tickets are - created for the project repository in a certain namespace or for the namespace in its - entirety, they can be reassigned with other project repositories belonging to the same - namespace. + 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. 28. **As a package maintainer, I want to be able to sync a fork with the upstream with a button click.** GitLab user interface provides a nifty button for allowing folks to update their repository @@ -228,7 +226,9 @@ Following is the investigation on GitLab based on the user stories collected. - establishing a two-way communication medium. 31. **A contributor, I'd like to be able to create repositories under a personal namespace for work related to Fedora.** - Please check the answer to the user story #27. + Every user associated with the GitLab deployment should have a personal namespace associated + where they can create their repositories and store the repositories forked from somewhere + else on the same deployment. 32. **As a package maintainer, I'd like to block branch creation outside of official ones, or remove branches outside of official ones.** GitLab provides means to name, manage and protect Git branches according to a certain @@ -407,10 +407,7 @@ Following is the investigation on GitLab based on the user stories collected. 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).** - 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. + Please check the answer to the user story #27. 58. **A package maintainer, I would like a push hook to block pushes to retired or EOL branches** GitLab supports Git Server @@ -426,11 +423,13 @@ Following is the investigation on GitLab based on the user stories collected. 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.** - 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. + The homepage of the said package (consisting of ``README.md`` file) can be updated to + reflect the changed status of the package and the name of the package can be added to a list + where potential packagers can pick it up from. While there is no 1:1 support in the feature + parity, we can have an issue tracker where people can request the orphanment of the packages + that they own and an automated script can be run that removes their access + (https://docs.gitlab.com/ee/user/permissions.html) from the said package repository and makes + the status reflecting changes. 61. **As a developer, I want to be query packages by their maintainers and vice versa.** Packages (or in this case, their representation as project repositories) have an ability of @@ -440,10 +439,10 @@ Following is the investigation on GitLab based on the user stories collected. 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.** - 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. + Extending the answer to the user story #60, a workflow can be established around the action + of requesting a package orphanment to an issue tracker - that in turn should kick off some + automation that ends up changing the project's homepage to reflect the status and enlisting + the package for potential packagers to "adopt". 63. **As a package maintainer, I need the forge to allow me to push branches that do not share history with other branches.** This is a Git technicality and as GitLab is based on Git, this should be possible. @@ -494,7 +493,7 @@ Following is the investigation on GitLab based on the user stories collected. 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.** - Please check the answer to the user story #57. + Please check the answer to the user story #27. 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.** Extending the answer to the user story #44 and user story #47, it is possible for GitLab to @@ -516,7 +515,11 @@ Following is the investigation on GitLab based on the user stories collected. 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).** - Please check the answer to the user story #8 and user story #9. + While GitLab provides a custom set of fields to be set for the issue tickets, those fields + are not as customizable as they are in Bugzilla. As a result, if this is a requirement people + will have to rely on the issue + templates (https://docs.gitlab.com/ee/user/project/description_templates.html#create-an-issue-template) + to fill in custom information. 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.** Good point! We can ask the GitLab folks nicely to add that I suppose.