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

Add 10 more answers to user stories

Browse source 
Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com>
This commit is contained in:
Akashdeep Dhar 2024-09-17 11:09:11 +05:30
parent 1a7c0cea77
commit 0ebeeca52a
2 changed files with 18 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -201,34 +201,34 @@ User stories
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.
61. **As a developer, I want to be query packages by their maintainers and vice versa.**
UNRESOLVED
Packages (or in this case, their representation as project repositories) have an ability of managing `collaborators <https://docs.codeberg.org/collaborating/invite-collaborators/>`_ associated with the project. Checking the packages associated with maintainers and checking maintainers associated with 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.**
UNRESOLVED
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.
63. **As a package maintainer, I need the forge to allow me to push branches that do not share history with other branches.**
UNRESOLVED
This is a Git technicality as Forgejo is based on Git, this should be possible.
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
If by empty commits, minimal changes to the specfile is inferred - this should be possible by contributors as long as they have minimal access of being able to READ the said project repository. For more access, it is strongly advised for the contributor to be onboarded onto the process so that they can conveniently keep contributing.
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
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).**
UNRESOLVED
Forgejo's UX feels a lot more 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.
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
Please check the answer to the user story #3 and user story #12.
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
Please check the answer to the user story #23 and user story #32.
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
Using GitLab CI, the replacement git forge can be configured to kickoff **mock builds** whenever pull requests are created and **actual builds** whenever pushes are made against the primary branch of the repository. This should facilitate packagers to immediately head over to Bodhi to schedule a new release after a pull request was merged.
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

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

@ -211,34 +211,34 @@ Following is the investigation on GitLab based on the user stories collected.
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.
61. **As a developer, I want to be query packages by their maintainers and vice versa.**
UNRESOLVED
Packages (or in this case, their representation as project repositories) have an ability of managing `members <https://docs.gitlab.com/ee/user/project/members/>`_ associated with the project. Checking the packages associated with maintainers and checking maintainers associated with 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.**
UNRESOLVED
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.
63. **As a package maintainer, I need the forge to allow me to push branches that do not share history with other branches.**
UNRESOLVED
This is a Git technicality and as GitLab is based on Git, this should be possible.
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
If by empty commits, minimal changes to the specfile is inferred - this should be possible by contributors as long as they have minimal access of being able to READ the said project repository. For more access, it is strongly advised for the contributor to be onboarded onto the process so that they can conveniently keep contributing.
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
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).**
UNRESOLVED
GitLab's UX feels a lot more polished as compared to Forgejo for those who are agnostic to tools. It is crucial to note that GitLab provides an `accessible <https://docs.gitlab.com/ee/development/fe_guide/accessibility/>`_ UX for the convenience of users using screen readers and keyboard-only functionality.
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
Please check the answer to the user story #3 and user story #12.
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
Please check the answer to the user story #23 and user story #32.
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
Using GitLab CI, the replacement git forge can be configured to kickoff **mock builds** whenever pull requests are created and **actual builds** whenever pushes are made against the primary branch of the repository. This should facilitate packagers to immediately head over to Bodhi to schedule a new release after a pull request was merged.
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