PR#174: Change user stories #27, #31, #57, #60, #62 and #78 - fedora-infra/arc

fedora-infra / arc

#174 Change user stories #27, #31, #57, #60, #62 and #78

Merged 7 months ago by t0xic0der. Opened 7 months ago by t0xic0der.

rant into main

Change user stories #27, #31, #57, #60, #62 and #78

Akashdeep Dhar • 7 months ago

b1aa1ba

docs/dist-git-comparison/forgejo.rst

file modified

+26 -21

		`@@ -185,11 +185,11 @@`
		`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 @@`
		`- 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 @@`
		`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 @@`
		`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 @@`

		`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 @@`
		`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 @@`
		`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 @@`
		`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.`

docs/dist-git-comparison/gitlab.rst

file modified

+25 -22

		`@@ -201,12 +201,10 @@`
		`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 @@`
		`- 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 @@`
		`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 @@`
		`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 @@`
		`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 @@`
		`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 @@`
		`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.`