This is the gathering place for the ARC investigation requirements. Please keep in mind that the current pagure functionality was already mapped by different ARC investigation
Please add your requirements in for of user stories:
As a package maintainer, I want to have all package builds listed on the homepage of the package.
As a package maintainer, I'd like to be able to run my own CI jobs on distgit PRs.
As a package maintainer, I'd like to be able to control the-new-hotness monitoring status from distgit
As a provenpackager, I should have push and merge access to all packages in the Fedora package collection
As a package maintainer and Fedora tooling maintainer, I'd like to be able to use Packit in both distgit and upstream repositories.
As a package maintainer, I'd like to have easy access links to Koji, Bodhi, and Koschei from the distgit repo.
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.
packager
(deleted)
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
As a package maintainer, I'd like to continue to be able to use fedpkg to fork repositories and otherwise interact with distgit.
fedpkg
Metadata Update from @t0xic0der: - Issue assigned to t0xic0der
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 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.
As a contributor, I want to be able to see who the current maintainer(s) are for a package
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 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
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.
As a contributor, I want to be able to see the contributors that have contributed to this package.
As a packager I want to be able to have commit access without being added to the bugzilla watch list
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
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 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.
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.
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.
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).
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).
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 a package maintainer, I want to be able to prevent direct push to git, and using merge requests process only.
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.
As a package maintainer, I want to be able to sync a fork with the pstream with a button click.
As a package maintainer, I wish we had CI compatible with Github Actions.
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.
A contributor, I'd like to be able to create repositories under a personal namespace for work related to Fedora.
As a package maintainer, I'd like to block branch creation outside of official ones, or remove branches outside of official ones.
As a contributor, I'd like the forge to be accessible (alt text for images, respecting whatwg standards for contrast, color blindness, aria support).
As a package maintainer I'd like to be able to delete a wrong file from the look aside cache.
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.
As a package maintainer, I wish to have a Security tab listing known CVE, and dependencies known CVE for the package.
As a package maintainer, I still want to be able to use Grokmirror to mirror the Forge packages locally.
QA Blocker Bugs Process / QA Freeze Exception Bugs Process
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.
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.
As an engineer involved in the release process, I should be able to notify the affected package maintainers and package testers.
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.
As an engineer involved in the release process, I want to be able to control the automated building and testing using comments.
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.
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.
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.
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.
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.
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.
As an engineer involved in the release process, I want to be able to automate ticketing workflows according to the phases of a release.
QA Blocker Bugs
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.
As a consumer of the fedora messaging bus, I want to be able to continue to receive messages in a JSON format on events.
As a developer/release engineer/QA/contributor, we need the new dist-git service to have hooks to attach new and existing CI pipelines.
As a contributor, I need to be able to login using my Fedora account.
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.
As a maintainer of dist-git(s), I would like to use industry-standard tools to maintain large files.
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.
As a package maintainer, I would like to be able to automatically transfer issues between packages (for example from ansible -> ansible-core).
A package maintainer, I would like a push hook to block pushes to retired or EOL branches
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.
As a policy enforcer, I want to be able to "orphan" packages that are not mine.
As a developer, I want to be query packages by their maintainers and vice versa.
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.
As a package maintainer, I need the forge to allow me to push branches that do not share history with other branches.
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).
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.
fedpkg fork && git remote rename zbyszek my && git push my rawhide:bin-sbin-merge
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).
@hankuoffroad Feel free to add your name to https://pagure.io/fedora-infrastructure/issue/12135
Thanks. I created a ticket for GitLab. https://pagure.io/fedora-infrastructure/issue/12148
I have access to Forgejo.
On Thu, Aug 22, 2024 at 11:04=E2=80=AFAM Michal Kone=C4=8Dn=C3=BD pagure@p= agure.io wrote:
zlopez added a new comment to an issue you are following: @hankuoffroad Feel free to add your name to https://pagure.io/fedora-infrastructure/issue/12135 To reply, visit the link below or just reply to this email https://pagure.io/fedora-infra/arc/issue/164
zlopez added a new comment to an issue you are following: @hankuoffroad Feel free to add your name to https://pagure.io/fedora-infrastructure/issue/12135
To reply, visit the link below or just reply to this email https://pagure.io/fedora-infra/arc/issue/164
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)
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)
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.
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.
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.
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).
@eclipseo wrote:
This may be in conflict with operations like mass-rebuilds, which may require direct pushes to many repositories. Processing them all via merge requests is likely infeasible.
Perhaps, rewritten: "As a package maintainer, I want all standard changes to require a merge request process, with only highly-privileged Fedora Release Engineering staff able to push directly".
As a package maintainer, I want to be able to prevent direct push to git, and using merge requests process only. This may be in conflict with operations like mass-rebuilds, which may require direct pushes to many repositories. Processing them all via merge requests is likely infeasible.
The trouble with a direct push to git is that if the mechanism exists, there's always the temptation to use it, even if limited to a subset of people. There's also the possibility that this mechanism can be used by a hijacked Fedora rel-eng account to push changes with less visibility.
IMHO its worth capturing @eclipseo 's requirement as written, and instead consider whether the evaluated Git forges have mechanisms to make merge requests automatable & low overhead, such that it is viable for scenarios like mass rebuilds too.
For example with GitLab you can git push <remote-name> <branch> -o merge_request.create merge_request.merge_when_pipeline_succeeds to automate opening a merge request and triggering it to merge without requiring any human interaction once CI passes. The CI pipeline could be written to detect a no-op "release number bump for mass rebuild" commit, and potentially skip overly onerous CI jobs if we want a light weight merge process. That could make using merge requests for mass rebuilds no more difficult than a direct push to git, but with the advantage of having better protection & visibility against mistakes or hijacked accounts.
git push <remote-name> <branch> -o merge_request.create merge_request.merge_when_pipeline_succeeds
As a package maintainer, I want to be able to prevent direct push to git, and using merge requests process only. This may be in conflict with operations like mass-rebuilds, which may require direct pushes to many repositories. Processing them all via merge requests is likely infeasible. The trouble with a direct push to git is that if the mechanism exists, there's always the temptation to use it, even if limited to a subset of people. There's also the possibility that this mechanism can be used by a hijacked Fedora rel-eng account to push changes with less visibility. IMHO its worth capturing @eclipseo 's requirement as written, and instead consider whether the evaluated Git forges have mechanisms to make merge requests automatable & low overhead, such that it is viable for scenarios like mass rebuilds too. For example with GitLab you can git push <remote-name> <branch> -o merge_request.create merge_request.merge_when_pipeline_succeeds to automate opening a merge request and triggering it to merge without requiring any human interaction once CI passes. The CI pipeline could be written to detect a no-op "release number bump for mass rebuild" commit, and potentially skip overly onerous CI jobs if we want a light weight merge process. That could make using merge requests for mass rebuilds no more difficult than a direct push to git, but with the advantage of having better protection & visibility against mistakes or hijacked accounts.
I like it, but it may be difficult to implement in a first pass. I suspect that reality will necessitate a "direct push" approach for version 1.0 of the new system. I'd be quite interested to work on implementing this suggestion after initial deployment, though.
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.
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.
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.
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.
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).
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).
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.
As a Fedora Badges junkie, I want to be able to receive badges for activities related to dist-git. In technical terms, the dist-git activities must be broadcast to the Fedora Message Bus (or however it's called nowadays).
Scalability is crucial for SaaS applications to handle varying workloads and user growth. The infrastructure should be designed to scale horizontally and vertically as needed.
User Story: As a SaaS administrator, I want the system architecture to support scalability, manually or automatically based on demand, so that we can maintain optimal performance during traffic spikes and efficiently handle user growth.
SaaS applications need to be highly available and reliable to ensure continuous service to end users.
User Story: As a SaaS administrator, I want the service architecture to be highly available, to ensure 24/7 operation with minimal downtime, so that end users may access and use the application whenever needed without interruptions.
Security is paramount in SaaS applications to protect sensitive customer data and maintain compliance.
User Story: As a SaaS administrator, I want robust security measures implemented across our infrastructure, including encryption, access controls, and regular security audits, so that we can protect our end users data and maintain their trust.
User Story: As a SaaS administrator, I want to quickly identify when the system is affected by CVEs, so that steps can be taken to plan upgrades to mitigate vulnerabilities.
Comprehensive monitoring and observability are crucial for maintaining the health and performance of SaaS applications.
User Story: As a SaaS administrator, I want a centralised monitoring and logging system that provides real-time insights into application performance, resource utilisation, and user experience, so that we can quickly identify and resolve issues before they impact users.
Implementing Infrastructure as Code practices ensures consistent and reproducible infrastructure deployments.
User Story: As a SaaS administrator, I want to manage our the system infrastructure using code that we can version control, easily replicate environments, and automate provisioning and configuration.
Proper multi-tenancy architecture is essential for SaaS applications to efficiently serve multiple end users while maintaining data isolation.
User Story: As a SaaS administrator, I want the application to be a secure multi-tenant system that efficiently shares resources among end users while ensuring complete data isolation, so that we can serve multiple clients cost-effectively without compromising security.
Implementing robust disaster recovery and backup strategies is essential for data protection and business continuity.
User Story: As a SaaS administrator, I want automated backup systems and a comprehensive disaster recovery plan in place, so that we can quickly recover from any unforeseen events and minimise data loss and downtime.
Having the ability to upgrade seemlessly between versions is vital.
User Story: As a SaaS administrator, I want to apply automated system upgrades, preferrably without causing system downtime, so we can continue to provide service to end users.
User Story: As a SaaS administrator, I want to safely apply database schema upgrades without causing outages or data loss.
As an QA engineer; Assign the bug to a package
As a QA engineer; Assign bug to multiple packages at the same time
As a QA engineer; re-assign the bug between packages without manually creating new bugs or without losing history.
As a QA engineer; package owners should be able to transfer bug report to any arbitary other package without losing history and the context.
As a QA engineer; every component should have a default owner assigned or group of owner if that component is owned by a SIG - eg Rust Packages by Rust SIG. This can be like rust-sig@fp.o as owner as well.
As a QA engineer; the new bug reports should get assigned to relavent owner of the component
As a QA engineer; existing bug which is being transferred by an package owner/ bug reporter should get assigned to the new owner and notifincation be set to all the stakeholders present in the bug.
As a QA engineer; bug reporter should be able to upload logs without any file extension limitation. This is required for syslog, user.journal.
As a QA engineer; I should be able to report CVE keeping things private. I should be able to restrict visibility of bug to specific privilage group/set of users
As a QA engineer; I should be able to enable privacy mode at any point of time in the lifecycle of the bug and that should not require attachments to become private by default. Only the data post the privacy gets enabled ; should become private not the whole bug report - unless it was reported as "private" in the first place
As a QA engineer; comments upto unlimited character or atleast 32k+ character which is current JIRA and RHBZ.
As a QA engineer; every bug should support different states of a bug which ought to also be a filter for sorting. viz NEW, POST, MODIFIED, ON_QA, CLOSED, NOTABUG, WORKSFORME, INVALID, DUPLICATE, ERRATA, EOL
As a QA engineer, I should be able to edit the comment 0 (first comment) of every issue multiple times to keep newly discovered information in one place.
As a QA engineer, I should be able to CC myself into one or multiple bugs
As a QA enginner, I should be able to tag "needinfo" to a specific bug and "needinfo" should correspond to one particular email/user. IF the user yet doesnt exist in the bug; needinfo should be able to add him and then notify him about his required presence
As a QA engineer; creation of a "Fake" component should be possible which should make it possible to list issues which are not directly mapped to any specific package (eg Distribution, LiveCD).This has multiple uses, from reporting bugs against some higher level component, or can be used for some automated processes.
As a QA engineer; I should be able to mark one bug as a duplicate of another bug. The information should be recorded in separate comments/in a structural way which represents how many bugs were marked redundant and when in a timeline sort of manner.
As a QA engineer; I should be able to mark one or more Fedora versions which are affected by the bug.
As a QA enginner; I will be able to Support extra metadata for the bug, like predefined keywords, a free-form whiteboard, links to other bugs (including in external trackers).
As a QA engineer; I should be able to tag people by username.
As a QA team; we should be able to send emails to a tracker, such that our inboxes don't get super flooded with notification.
As a QA team, we should be list all the bugs reports for a package, filter and sort them.
As a QA, I should be able tot sort active/inactive bugs that were reported by a user across all components and all packages ; in a specific timeframe.
As a QA, the API should have read-only acess without authetication.
As a QA, all the above mentioned operations should be possible with a API and it should support batch operation.
As a QA , I should be able to define multiple links to external trackers (upstream bug reports)
As a QA; I should be able to fetch Query structured object info about a bug through API, ideally without API authorization.
As a QA;Access bug fields through API, including status, component, version, summary, blocks/depends-on, whiteboard (a free-form field), keywords or any other special fields
As a QA; Edit bug fields through API.
As QA; Create a new bug through API and CC users/SIG for that component.
As QA; Mark an API user as a bot (so that it’s not subject to rate limiting, captcha and similar)
As QA; Bug relationships - “bug X blocks bug Y”, or any other arbitrary relationship, doesn’t need to be named “blocking”. Query all bugs which are in a relationship with bug Y.
As QA ; Batch API - querying 50 bugs in a single call instead of individually.
As QA;API support for querying only bugs that have been modified after $timestamp. For Bugzilla, this made queries faster.
As QA; When an API query returns lots of results (e.g. thousands or more), either support pagination or allow to return the full set, even if very large. No hard cut-off point. If there is one, please let us know!
As QA;A process should exist for how to request a new metadata field to be added to bugs/issues (so that we can request adding new fields for e.g. accepted/rejected blocker/fe or some other field when needed)
As a maintainer of the blocker discussion;API to create a new ticket, edit the ticket description at any time (even when some later comments are added), read contents of all present comments, add new comments, and close the ticket
As a maintainer of blocker bugs app ; Receive API notifications (hooks, messages) when comments are added or edited.
As a maintainer of blocker bugs app; the said API should have ability to add people to groups, so that we can use a certain group as moderators/administrators. Alternatively, integration with FAS (so that we can use FAS groups instead).
As a packager dashboard maintainer; I should be able to fetch we fetch the following fields: ['blocks', 'comments.id'**, 'creation_time', 'creator', 'groups', 'id', 'keywords', 'last_change_time', 'priority', 'severity', 'status', 'summary', 'version', 'whiteboard'] by API
As a packager Dashboard maintainer; I should be able to fetch structured objects of pull Request and their CI state
As a packager dashboard maintainer; I should have API to fetch all existing packager groups, and their packages and members, and their ACL level
As a packager dashboard maintainer; I should be able to do a git tree file walk
As QA who is trying to gather stats, I should be able to fetch bugID and ref them to test days app.
As a QA who is trying to gather details, I should be able to cross check fas and ldap/kerberos and suggest via CSV the list of users who are probably redhat employee
As a automation QA, I should be able to benefit from integration between Fedora CI and dist-git
As a QA, the Bodhi updates should reflect Bugs assigned to a build or build overide. As tester, if these issues are coming from specific component, we should be able to tag them appropriately.
As a QA, bugs during validation testing are covered by mainly wiki templates and this is used to generate stats on bugs filed/resolved during test days and validation tests. The new issue tracker, should ideally have a process to resolve/integrate the bugs in the existing wikis.
As a QA, Fedora Easy Karma refs bugzilla and the new issues should ideally be discoverable https://pagure.io/fedora-easy-karma/blob/master/f/fedora-easy-karma.py
As a QA, ABRT should be able to report bugs to the new tracker. Currently ABRT's automatic reporting files bugs directly to RHBZ with Logs and all details relavant for RCA.
As a QA, Getting a Bugzilla’s replacement(s) which is already included in openQA’s supported trackers is needed- see https://github.com/os-autoinst/openQA/blob/8d1e8da7adabeb34d0499fcff966106e07c2fbd4/lib/OpenQA/Utils.pm#L40 and usage of BUGREFS and BUGURLS in that file
As a maintainer of packages in Fedora, I would like the ability to move a ticket assigned to my project to a new project.
As an example, . I get a few tickets every month against "fedora-release" because people just use that as a stand-in for "I don't know what package to report against"
As a Fedora CI maintainer, I would like to have the ability to enable mandatory checks for each dist-git pull request to ensure Fedora distribution stability.
As a Fedora forge administrator, I would like to have legally-enforceable assurances that features available in the open-source (or "community edition") of the forge will remain that way in the future in order to prevent platform decay from degrading the functionality.
As a Fedora administrator, I would like to be able to restrict the addition of new comaintainers to a package to the list of approved Fedora packagers.
In other words, comaintainers should be required to join the Packagers group, following the normal sponsorship process.
As a package maintainer, I want an RPM build (in Copr and/or Koji) to be automatically submitted for all pull-requests and changes in them.
As a package reviewer, I want all packages submitted for a Fedora package review, as well as all changes made to them during the review process, to be automatically built in Copr with the fedora-reivew tool ran on them. And I want the results reported back to the review ticket.
fedora-reivew
As a package reviewer, I want the fedora-review tool to continue working with the Bugzilla replacement
fedora-review
As a contributor, I'd like to be able to locate all of my activity in the forge using its search features, including any and all comments I've left on issues or PRs, for any/all projects.
(IOW, equivalents to GitHub's is:issue commenter:@me or is:pr commenter:@me site-wide searches.)
is:issue commenter:@me
is:pr commenter:@me
This is something that AFAICT is simply not possible in GitLab — you can search for Author := <username> to find issues or MRs you created, but not ones you've merely commented on, unless you also associated yourself with it in some other way. (Like leaving a reaction: My-Reaction := Any, or getting it assigned to you: Assignee := <username>).
Author := <username>
My-Reaction := Any
Assignee := <username>
Log in to comment on this ticket.