Infrastructure/arc
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com>
This commit is contained in:
Akashdeep Dhar 2024-10-01 14:15:15 +05:30
parent 7648278ec5
commit b1aa1ba086
2 changed files with 51 additions and 43 deletions
Download patch file Download diff file Expand all files Collapse all files

47
docs/dist-git-comparison/forgejo.rst
View file

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

47
docs/dist-git-comparison/gitlab.rst
View file

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