From Forgejo — ARC notes documentation
- 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 (Automatically Linked References in Issues, Pull Requests and Commit Messages | Forgejo – Beyond coding. We forge.) 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.
- 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 (API Usage | Forgejo – Beyond coding. We forge.) 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.
Isn’t that a bit contradicting? Or does “automatically transfer issues” mean it happens right when the issue is created?
- 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 (Repository Permissions | Forgejo – Beyond coding. We forge.) who can archive a said repository.
No, I want the package to be orphaned, not archived. What does orphaned mean is documented at Policy for Orphan and Retired Packages :: Fedora Docs but tl;dr I want the be able to remove the main admin of the package and let the package be available for others to claim.
- 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.
The same. Orphaning is not archiving. The user story focuses on ability to orphan (“abandon”) a repository and the ability for others to claim it. In the meantime, in the “abandoned” state, it is still possible to commit to it, it is not archived.
- 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).
If by empty commits, minimal changes to the specfile is inferred…
No, this literally means empty commits. Commits with no changes whatsoever. The rest of the answer is not relevant to the user story. The “driveby contributor” aspect means “I have no way of committing directly, so I need to open a PR”. Currently, this is broken in Pagure: Issue #5270: Cannot create a pull request with empty commit - pagure - Pagure.io
- 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.
This use case is not relevant to use cases 8 and 9.