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

Add the newly added user stories in the mix

Browse source 
Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com>
This commit is contained in:
Akashdeep Dhar 2024-09-11 11:56:33 +05:30
parent e2e6bf7b8d
commit 88ea372eac
3 changed files with 314 additions and 53 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -179,3 +179,90 @@ Following is the investigation on GitLab based on the user stories collected.
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.**
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
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
53. **As a contributor, I need to be able to login using my Fedora account.**
UNRESOLVED
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
55. **As a maintainer of dist-git(s), I would like to use industry-standard tools to maintain large files.**
UNRESOLVED
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
57. **As a package maintainer, I would like to be able to automatically transfer issues between packages (for example from ansible -> ansible-core).**
UNRESOLVED
58. **A package maintainer, I would like a push hook to block pushes to retired or EOL branches**
UNRESOLVED
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
60. **As a policy enforcer, I want to be able to "orphan" packages that are not mine.**
UNRESOLVED
61. **As a developer, I want to be query packages by their maintainers and vice versa.**
UNRESOLVED
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
63. **As a package maintainer, I need the forge to allow me to push branches that do not share history with other branches.**
UNRESOLVED
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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