258 lines
29 KiB
ReStructuredText
258 lines
29 KiB
ReStructuredText
.. _forgejo:
|
|
|
|
Forgejo
|
|
======
|
|
|
|
User stories
|
|
------------
|
|
|
|
1. **As a package maintainer, I'd like to be able to run my own CI jobs on distgit PRs.**
|
|
While added as recently as 2023-02-27, Forgejo supports an integrated continuous integration system called Actions (https://forgejo.org/2023-02-27-forgejo-actions/). For specific purposes where a custom environment is required, even custom Forgejo runners (https://code.forgejo.org/forgejo/runner) can be associated with a certain project repository or project namespace.
|
|
|
|
2. **As a package maintainer, I'd like to be able to control the-new-hotness monitoring status from distgit.**
|
|
Release Monitoring has an API (https://release-monitoring.org/static/docs/api.html) that can be attached as a webhook to an action on Forgejo's end. This should help with controlling monitoring status of a certain package. This would require some work as there is nothing in Forgejo that intrinsically supports this usecase.
|
|
|
|
3. **As a provenpackager, I should have push and merge access to all packages in the Fedora package collection.**
|
|
While Forgejo provides for various levels of access control for the repositories and namespaces available, they are not as fine grained as those in GitLab. Only three roles are available for collaborators (https://docs.codeberg.org/collaborating/) of a project (i.e. administrator, read and write).
|
|
|
|
For a more universal access across various packages for users belonging to the provenpackager group, the administrator access level can be used - although it is strongly discouraged as that might open circumstances up for potentially destructive actions (https://docs.codeberg.org/collaborating/repo-permissions/).
|
|
|
|
4. **As a package maintainer and Fedora tooling maintainer, I'd like to be able to use Packit in both distgit and upstream repositories.**
|
|
Packit does not support Forgejo but with some CI magic, Packit can be made to work on the platform. Owing to the scale of packages that Fedora Project houses, this would be ruled out as specific configuration would be necessitated per package scenario. Setting up Packit workflow in the Forgejo Actions cannot be reliably automated and the maintenance adds further workload on the Fedora Infrastructure team and the Packit team.
|
|
|
|
5. **As a package maintainer, I'd like to have easy access links to Koji, Bodhi, and Koschei from the distgit repo.**
|
|
Forgejo supports the use of badges (https://forgejo.org/docs/latest/user/readme-badges/) that makes it possible to add badges to the project documentation. While these are mostly used for showing status about the pipeline, statistics about the test coverage and information about the latest release - these can also be used for keeping links for Koji, Bodhi and Koschei for the said project.
|
|
|
|
Take, for instance, these badges can be configured automatically whenever the repository is created for the first time by the releng-scm-bot either in the repository level or as a part of textual links in the README.md file in the project repository. Alternatively, the URL field for the project can be configured to store the Fedora Packages URL (https://packages.fedoraproject.org/)."
|
|
|
|
6. **As a packager sponsor/mentor, I'd like to help users from outside the packager make their first PR without requiring special tooling or authentication schemes.**
|
|
As mentioned in the answer to the user story #3, it can be tricky to limit the access with barely three access levels of widely varied powers. Although as long as the project against which a PR (https://forgejo.org/docs/latest/user/pull-requests-and-git-flow/) is to be made is publicly visible, all the users having an account on the Forgejo system should have a READ access to the project. This enables them to fork the project to their own namespace, make necessary changes and make a PR against the main repository.
|
|
|
|
7. **As a package maintainer and tooling maintainer, I'd like to be able to set Depends-on: and Blocks: relationships between tickets in the issue tracker.**
|
|
Forgejo provides rudimentary issue tracking capabilities and while issues can be linked against each other superficially with the use of comments under an issue ticket thread (https://forgejo.org/docs/latest/user/linked-references/), they cannot be logically bound with each other. There is extensive customizations of labels possible (https://forgejo.org/docs/latest/user/labels/) for scoping purposes.
|
|
|
|
8. **As a package maintainer, I'd like to continue to be able to use fedpkg to fork repositories and otherwise interact with distgit.**
|
|
Forgejo provides with a comprehensive REST API (https://forgejo.org/docs/latest/user/api-usage/) that can be used to extend the Forgejo instance's functionality using external applications and services. Fedpkg (https://pagure.io/fedpkg) needs to be reworked to associate the REST API endpoint that allows for interacting with the deployed instance in accordance to the REST API schema of Forgejo.
|
|
|
|
9. **As a package maintainer, I want to be able to control all aspects of the pull request process (read comments, reply to comments, approve PRs, merge PRs, etc) via an REST API to allow creation command line tools to automate work that otherwise requires a pointy-clicky web UI.**
|
|
As mentioned in the answer to the user story #8, Forgejo provides with a comprehensive REST API (https://forgejo.org/docs/latest/user/api-usage/) that can be used to perform actions that control all aspects of a pull request process (https://forgejoroute-communishift-forgejo.apps.fedora.cj14.p1.openshiftapps.com/api/swagger#/repository). This REST API can be included in command line tools for automation.
|
|
|
|
10. **As a package maintainer, I want to be able to mark a PR to automatically merge if-and-only-if a running CI pipeline has succeeded. This allows reviewing and approving a PR, and moving onto new work, without having to wait around to see if CI passes or not. The PR only needs re-visiting manually if CI failed.**
|
|
An auto-merge functionality is not available on Forgejo. While it can be made possible with the use of webhooks called on the event of a successful continuous integration job closure with the combination of Forgejo Actions (https://forgejo.org/docs/v1.20/user/actions/) and Forgejo webhooks (https://forgejo.org/docs/v1.19/user/webhooks/), the setup process cannot be reliably automated and the maintenance adds further workload on the Fedora Infrastructure team.
|
|
|
|
11. **As a contributor, I want to be able to see who the current maintainer(s) are for a package.**
|
|
Please check the answer to the user story #3.
|
|
|
|
12. **As a contributor, I want to be able to request to join the maintainer(s) for a package, either as a watcher (just notified of all PRs), or as a developer (participate in MR process), or as a maintainer (control all aspects of the package, ie user ACLs). Joining as merely a watcher should not require approval by current maintainers.**
|
|
As mentioned in the answer to the user story #6, as long as the project sought here is publicly visible, all the users having an account on the Forgejo system should have a READ access to the project. This enables them to watch a project (or its assets like branches, issue tickets and pull requests) for notifications (https://forgejo.org/docs/v1.19/user/email-settings/) without needing to add them into the project groups.
|
|
|
|
The notifications settings are rudimentary in nature and hence, watching a repository would subscribe a user to all events associated to a certain repository (eg. creation of issue tickets, pull requests, comments etc.) without the finegrained settings of what events to be subscribed to and what events to ignore (https://forgejo.org/docs/v1.19/user/email-settings/#watching-repositories).
|
|
|
|
13. **As a package maintainer, I want opening a MR to automatically create a scratch-build. Approving the MR, should be able to either automatically promote the scratch-build to non-scratch status, or create a new non-scratch build. The latter should have a way to disable for packages with huge build times where creation of one build for multiple approved MRs is desirable for efficiency.**
|
|
Creation of a scratch builds based on the branch from which a pull request was created is possible with the use of Forgejo Actions. Furthermore, the approval of a pull request can be associated with a Forgejo webhook (https://forgejo.org/docs/v1.19/user/webhooks/) which in turn should trigger the normal builds. Conditional cancelling of jobs due to them being overridden by a more recent job is not possible in Forgejo and hence, such jobs have to be manually cancelled.
|
|
|
|
14. **As a package maintainer, I would like to see the dependencies of this package, and what packages that are required by this package on web UI.**
|
|
There is no inbuilt method of implementing dependencies across the repositories present on the Forgejo system and hence relying on the MDAPI results is necessitated.
|
|
|
|
Focussing on making lemonades out of whatever lemons we have at hand, the endpoints PKG (eg. https://mdapi.fedoraproject.org/rawhide/pkg/nano) and REQUIRES (eg. https://mdapi.fedoraproject.org/rawhide/requires/nano) can be used to automatically populate the packages required by the project's package and the packages requiring the project's package respectively in custom files when the associated package's repositories are being created for the first time."
|
|
|
|
15. **As a contributor, I want to be able to see who the current maintainer(s) are for a package.**
|
|
Please check the answer to the user story #11.
|
|
|
|
16. **As a contributor, I want to be able to see the contributors that have contributed to this package.**
|
|
Please check the answer to the user story #11.
|
|
|
|
17. **As a packager I want to be able to have commit access without being added to the bugzilla watch list.**
|
|
Please check the answer to the user story #12.
|
|
|
|
18. **As a community member I want the ability to be added to the bugzilla watch list for a package without having commits or being in the packager group.**
|
|
Please check the answer to the user story #12.
|
|
|
|
19. **As a Fedora Infrastructure member, I want to ensure people who sign in to watch a package on bugzilla have a valid bugzilla account associated with their FAS account.**
|
|
As we plan on deprecating Bugzilla going forward for its use in the packaging workflow and introducing the ticketing mechanism associated with the git forge solution that we choose as a replacement for the same, the notification settings pertaining to certain users can be configured per repository (https://forgejo.org/docs/v1.19/user/email-settings/) as long as they have an account in the said git forge solution.
|
|
|
|
20. **As a user of Fedora, not necessarily a member of the Fedora Project, I want to receive information about Fedora packages in the form of readable HTML documents, not in the form of programs (in Javascript or Web Assembly) that I must execute before I get to see the information.**
|
|
I am afraid Dist Git might not be the correct place for this requirement. Please defer to using Fedora Packages (https://packages.fedoraproject.org/) for obtaining information about packages available in the official Fedora Project repositories. We do not want to duplicate efforts by reproducing features in Dist Git that are already implemented in an associated project in Fedora Infrastructure.
|
|
|
|
21. **As a security-conscious packager, I want to interact with the web interface without downloading and running programs from a bunch of third parties. I should at most need to whitelist Javascript and Web Assembly from fedoraproject.org only.**
|
|
The set of JavaScript and WebAssembly tools involved in running a managed Forgejo deployment are made available from the source hosting the deployment and not anywhere else. This has been analysed by observing the network behaviour made in a browser environment against a managed Forgejo deployment intended for testing.
|
|
|
|
22. **As a member of the Free Software movement, I want all parts of the system to be Free Software. That includes both server-side software and all Javascript, Web Assembly and/or CSS that my browser will download and execute.**
|
|
Licensed under the permissive MIT license, Forgejo is a free and open source software. The repository of the project codebase can be found at https://codeberg.org/forgejo/forgejo. There are no separate enterprise and free versions of the project.
|
|
|
|
23. **As a package maintainer, I want to be able to use a pull-request-only workflow for specific packages (like packages that could break a lot of things, or packages that are security sensitive).**
|
|
With the use of Protected branches mechanism (https://forgejo.org/docs/latest/user/protection/#protected-branches) of Forgejo, one can ensure that changes to a certain set of branches can only be introduced using a pull request workflow.
|
|
|
|
24. **As a package maintainer with provenpackager or scm-admin rights, I want to be able to circumvent pull-request-only requirements on packages when pushing changes (i.e. mass rebuilds).**
|
|
Please check the answer to the user story #3.
|
|
|
|
25. **As a package maintainer, I'd like existing STI and TMT CI tests to continue working while also providing a simpler, more familiar YAML-based format.**
|
|
As mentioned in cell F2, as long as the Forgejo Actions is configured properly to support STI and TMT CI tests, they should work fine on Forgejo like they do on Pagure - both in environments provided within the managed Forgejo infrastructure and in custom Forgejo runners introduced externally.
|
|
|
|
26. **As a package maintainer, I want to be able to prevent direct push to git, and using merge requests process only.**
|
|
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.
|
|
|
|
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 is not as seamless as clicking on a button, Forgejo does note the instructions on how that can be done in the official documentation (https://forgejo.org/docs/latest/user/pull-requests-and-git-flow/#keep-it-up-to-date-rebase-pull-requests-to-upstream). Here again, this is NOT as convenient as doing things with a button click - but hey, it is possible.
|
|
|
|
29. **As a package maintainer, I wish we had CI compatible with Github Actions.**
|
|
While GitHub Actions and Forgejo Actions are not inherently compatible with each other, they follow a similar set of syntax and semantics of the workflow files used in the former system. But "they are not and will never be identical (https://forgejo.org/docs/v1.20/user/actions/#:~:text=they%20are%20not%20and%20will%20never%20be%20identical).
|
|
|
|
30. **As a contributor, I'd like to be able to interact with git and distgit via email, namely to reply to issue and PR comments.**
|
|
As mentioned in the answer to the user story #12, the notification settings can not only be used to for obtaining information via email about the activities associated to a certain namespace/project repository but also to reply to issues or pull requests via email as well - 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.
|
|
|
|
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.
|
|
|
|
33. **As a contributor, I'd like the forge to be accessible (alt text for images, respecting whatwg standards for contrast, color blindness, aria support).**
|
|
Accessibility seems to be an ongoing effort in Forgejo (https://codeberg.org/forgejo/discussions/issues/49).
|
|
|
|
34. **As a package maintainer I'd like to be able to delete a wrong file from the look aside cache.**
|
|
While there was no documentation found on Git LFS support on the official Forgejo documentation, some of it was found on the Codeberg documentation (https://docs.codeberg.org/git/using-lfs/). As long as Fedpkg is configured to support the same protocol of creating, accessing, updating and deleting tarball archives, the lookaside cache can be configured at ease.
|
|
|
|
35. **As a package maintainer, I'd wish to be able to see a tree of the Depends-on and Blocks bugs relationship, and export it to JSON or any easily processable document.**
|
|
Please check the answer to the user story #7.
|
|
|
|
36. **As a package maintainer, I wish to have a Security tab listing known CVE, and dependencies known CVE for the package.**
|
|
There is no inbuilt method of managing dependencies across the repositories present on the Forgejo system and hence relying on third party services like Renovate is is necessitated (https://docs.renovatebot.com/modules/platform/gitea/).
|
|
|
|
Focussing on making lemonades out of whatever lemons we have at hand, Renovate can be automatically configured to help report CVEs related to the dependencies and remedial pull requests that help with upgrading from the affected version whenever the repositories are created for the first time by releng-scm-bot.
|
|
|
|
37. **As a package maintainer, I still want to be able to use Grokmirror to mirror the Forge packages locally.**
|
|
To Grokmirror's credit (https://github.com/mricon/grokmirror), the project is open enough to allow for mirroring from and mirroring to most Git forges as long as their JSON schema for their REST API is readily available. It should be possible to mirror repositories available on the chosen Git forge replacement to people's mirrors as long as the destination repos are empty as mentioned in Grokmirror.
|
|
|
|
Additionally, repository mirroring (https://forgejo.org/docs/latest/user/repo-mirror/) is a feature available in Forgejo with the support for various Git forges for contents of the repository. One can also make use of Forgejo Actions (https://forgejo.org/docs/v1.20/user/actions/) to set a cronjob or event driven interaction.
|
|
|
|
38. **As an engineer involved in the release process, I want to be able to track blocker bugs and freeze exception bugs in the chosen issue tracker.**
|
|
Forgejo provides issue trackers (https://forgejo.org/docs/v1.19/user/issue-tracking-basics/) associated with a certain namespace for purposes like discussing the implementation of an idea, tracking tasks and work progress, accepting feature proposals, questions, requests or bugs, elaborating on code implementations etc.
|
|
|
|
Additionally, as mentioned in the answer to the user story #7, if the interweaving of the issue tickets across various organizations is a requirement due to cases like a certain package depending on another package - this can be facilitated by ensuring that the issue tracker associated with the parent organization of the said packages are used.
|
|
|
|
39. **As an engineer involved in the release process, I want to be able to properly triage the state of the blocker bugs and freeze exception bugs with Kanban boards.**
|
|
Forgejo makes use of rudimentary Kanban boards to manage projects having multiple issue tickets and pull requests associated (https://forgejo.org/docs/latest/user/project/).
|
|
|
|
40. **As an engineer involved in the release process, I should be able to notify the affected package maintainers and package testers.**
|
|
Please check the answer to the user story #12.
|
|
|
|
41. **As an engineer involved in the release process, I want to be able to plan for the effects on release phases (Alpha, Beta, Final) using the Gantt chart.**
|
|
Forgejo does not support roadmaps or time tracking in issue tickets.
|
|
|
|
42. **As an engineer involved in the release process, I want to be able to control the automated building and testing using comments.**
|
|
As mentioned in the answer to the user story #13, the events possible with Forgejo Actions like the creation of scratch builds and actual builds can be controlled with the intelligent use of webhooks (https://forgejo.org/docs/v1.19/user/webhooks/) that Forgejo supports. These webhooks can be triggered internally on the selected git forge as a consequence of activities like commenting under a ticket or a pull request or externally with the use of projects like Webhook To Fedora Messaging (https://github.com/fedora-infra/webhook-to-fedora-messaging).
|
|
|
|
43. **As an engineer involved in the release process, I want to be able to triage the priorities of the blocker bugs and freeze exception bugs in the chosen issue tracker.**
|
|
Please check the answer to the user story #7.
|
|
|
|
44. **As an engineer involved in the release process, I want to be able to speed up the creation of blocker bugs and freeze exception bugs with the use of issue ticket templates.**
|
|
Forgejo provides for issue tickets and pull request templates (https://forgejo.org/docs/latest/user/issue-pull-request-templates/).
|
|
|
|
45. **As an engineer involved in the release process, I want to be able to limit the access of ticket modification to a certain set of people.**
|
|
Please check the answer to the user story #3.
|
|
|
|
46. **As an engineer involved in the release process, I want to be able to access the chosen issue tracker with the use of an HTTP API.**
|
|
Please check the answer to the user story #7.
|
|
|
|
47. **As an engineer involved in the release process, I want to be able to show related issue tickets to the reporter to avoid repeated rejections.**
|
|
It is at the reporter's discretion to view the issue tickets that have been opened so far to confirm if the issue that they plan on reporting has already been reported as Forgejo does not perform an automatic lookup on the existing issue tickets based on the substrings of the potential new issue ticket.
|
|
|
|
48. **As an engineer involved in the release process, I want to be able to use the already established Bug Status Workflow as closely as possible.**
|
|
Please check the answer to the user story #7.
|
|
|
|
49. **As an engineer involved in the release process, I want to be able to automate ticketing workflows according to the phases of a release.**
|
|
Tracking of project milestones is not possible with Forgejo and hence, it has to be compensated with the use of meta-issues (i.e. overarching issue tickets that track the progress made across various granularly focused issue tickets).
|
|
|
|
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
|