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

Limit the document to have 100 chars per line

Browse source 
Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com>
This commit is contained in:
Akashdeep Dhar 2024-09-25 11:31:52 +05:30
parent e6b7319149
commit 7648278ec5
2 changed files with 582 additions and 136 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1,7 +1,7 @@
.. _forgejo:
Forgejo
======
=======
User stories
------------
@ -9,61 +9,125 @@ User stories
Following is the investigation on Forgejo based on the user stories collected.
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.
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.**
For this to work on Forgejo, we would need to have metadata stored in repository. This could be
for example stored in `.metadata` file. Anybody with commit rights to repository will be able to
change the monitoring settings.
For this to work on Forgejo, we would need to have metadata stored in repository. This could
be for example stored in `.metadata` file. Anybody with commit rights to repository will be
able to change the monitoring settings.
Or we can leverage Forgejo badges feature (https://forgejo.org/docs/latest/user/readme-badges/),
which isn't supported by Forgejo API yet. We can ask Forgejo developers to add support for
badges. The-new-hotness will need to be able to access the badges by different means till then
(for example checking specific badges URLs).
Or we can leverage Forgejo badges feature (https://forgejo.org/docs/latest/user/readme-badges/),
which isn't supported by Forgejo API yet. We can ask Forgejo developers to add support for
badges. The-new-hotness will need to be able to access the badges by different means till
then (for example checking specific badges URLs).
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).
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/).
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.
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.
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/)."
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.
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.
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.
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://codeberg.org/api/swagger#/repository). This REST API can be included in command line tools for automation.
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://codeberg.org/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.
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.
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).
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.
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.
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.
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.
@ -78,40 +142,74 @@ Following is the investigation on Forgejo based on the user stories collected.
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.
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.
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.
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.
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.
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 the answer to the user story #1, 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.
As mentioned in the answer to the user story #1, 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.
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.
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)".
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.
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.
@ -120,31 +218,56 @@ Following is the investigation on Forgejo based on the user stories collected.
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).
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.
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 necessitated (https://docs.renovatebot.com/modules/platform/gitea/).
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
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.
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.
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.
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.
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.
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/).
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.
@ -153,13 +276,20 @@ Following is the investigation on Forgejo based on the user stories collected.
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).
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 support for issue tickets and pull request templates (https://forgejo.org/docs/latest/user/issue-pull-request-templates/).
Forgejo provides support 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.
@ -168,64 +298,109 @@ Following is the investigation on Forgejo based on the user stories collected.
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.
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).
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.**
With the introduction of the Webhook To Fedora Messaging (https://github.com/fedora-infra/webhook-to-fedora-messaging/ project, webhooks (https://forgejo.org/docs/v1.19/user/webhooks/) on the platform can be integrated with the service to stay posted about the activities at the forge end.
With the introduction of the Webhook To Fedora
Messaging (https://github.com/fedora-infra/webhook-to-fedora-messaging/) project,
webhooks (https://forgejo.org/docs/v1.19/user/webhooks/) on the platform can be integrated
with the service to stay posted about the activities at the forge end.
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.**
Forgejo supports webhooks (https://forgejo.org/docs/v1.19/user/webhooks/) so as long as we are able to leverage the features with our existing CI pipelines - the service should be able to function similarly to the existing Pagure based git forge.
Forgejo supports webhooks (https://forgejo.org/docs/v1.19/user/webhooks/) so as long as we
are able to leverage the features with our existing CI pipelines - the service should be
able to function similarly to the existing Pagure based git forge.
53. **As a contributor, I need to be able to login using my Fedora account.**
Forgejo supports FreeIPA (https://forgejo.org/docs/v1.19/user/authentication/#freeipa) and hence, plugging in support for authentication using Fedora Account System account should be possible. This has been implemented to various degrees of success in the testing deployment (https://forgejoroute-communishift-forgejo.apps.fedora.cj14.p1.openshiftapps.com/) of Forgejo and hence, the same knowledge can be made use of in this implementation. This extends to group based access controls as well which means that Fedora Account System groups can be used to map access levels at the Forgejo end.
Forgejo supports FreeIPA (https://forgejo.org/docs/v1.19/user/authentication/#freeipa) and
hence, plugging in support for authentication using Fedora Account System account should be
possible. This has been implemented to various degrees of success in the testing
deployment (https://forgejoroute-communishift-forgejo.apps.fedora.cj14.p1.openshiftapps.com/)
of Forgejo and hence, the same knowledge can be made use of in this implementation. This
extends to group based access controls as well which means that Fedora Account System groups
can be used to map access levels at the Forgejo end.
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.**
Being a free and open source software, we should be able to deploy multiple instances of Forgejo with each instance having its own purpose and authentication backend without any issues.
Being a free and open source software, we should be able to deploy multiple instances of
Forgejo with each instance having its own purpose and authentication backend without any
issues.
55. **As a maintainer of dist-git(s), I would like to use industry-standard tools to maintain large files.**
Please check the answer to the user story #34.
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.**
While I suggest rebasing and applying changes based on the review comments for a cleaner Git history, it is technically impossible (https://forgejo.org/docs/latest/user/pull-requests-and-git-flow/) for collaborators to apply the suggest changes with a click of a button on Forgejo.
While I suggest rebasing and applying changes based on the review comments for a cleaner
Git history, it is technically
impossible (https://forgejo.org/docs/latest/user/pull-requests-and-git-flow/) for
collaborators to apply the suggest changes with a click of a button on Forgejo.
57. **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 (https://forgejo.org/docs/latest/user/api-usage/) 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.
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 (https://forgejo.org/docs/latest/user/api-usage/) 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.
58. **A package maintainer, I would like a push hook to block pushes to retired or EOL branches**
While a relevant documentation could not be found on the matter, as Forgejo is based on Git version control system - it should be theoretically possible to conditionalize the rejection of a pushed commit whenever they are made against a branch that is stated to be retired or EOLed. The absence of a documentation means that more efforts has to be put into it.
While a relevant documentation could not be found on the matter, as Forgejo is based on Git
version control system - it should be theoretically possible to conditionalize the rejection
of a pushed commit whenever they are made against a branch that is stated to be retired or
EOLed. The absence of a documentation means that more efforts has to be put into it.
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.**
It is possible to configure the access levels per branch dependent on certain branch names or branch names matching a certain pattern in Forgejo. The feature is called "Branch and tag protection (https://forgejo.org/docs/v1.19/user/protection/)".
It is possible to configure the access levels per branch dependent on certain branch names
or branch names matching a certain pattern in Forgejo. The feature is called "Branch and tag
protection" (https://forgejo.org/docs/v1.19/user/protection/).
60. **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 (https://forgejo.org/docs/v1.19/user/repo-permissions/) who can archive a said repository.
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.**
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.
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.**
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.
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.
63. **As a package maintainer, I need the forge to allow me to push branches that do not share history with other branches.**
This is a Git technicality and 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).**
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.
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.**
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).**
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.
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).**
Please check the answer to the user story #3 and user story #12.
@ -234,25 +409,46 @@ Following is the investigation on Forgejo based on the user stories collected.
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
Certain continuous integration workflows can be associated to check for NVR changes
associated with a certain commit and following that the Forgejo REST
API (https://forgejo.org/docs/latest/user/api-usage/) can be made use of to push tags to the
source repository. This can help with conveniently determining which commits were used to
create particular builds. This operation is involved more with the Git workflow so all kinds
of git forges should be able to do this.
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.**
Using Forgejo Actions (https://forgejo.org/docs/v1.20/user/actions/), 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.
Using Forgejo Actions (https://forgejo.org/docs/v1.20/user/actions/), 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.**
Please check the answer to the user story #70.
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).**
One can declare custom workflow configuration on Forgejo Actions (https://forgejo.org/docs/v1.20/user/actions/) in addition to the standard tests and builds (draft and actual) facilitated by Fedora Project. While still in alpha, self proposed Forgejo Runners (https://code.forgejo.org/forgejo/runner) is expected to be able to ensure that any testing that has sensitive information or requires specialized resources are addressed suitably - when it becomes production ready.
One can declare custom workflow configuration on Forgejo
Actions (https://forgejo.org/docs/v1.20/user/actions/) in addition to the standard tests and
builds (draft and actual) facilitated by Fedora Project. While still in alpha, self proposed
Forgejo Runners (https://code.forgejo.org/forgejo/runner) is expected to be able to ensure
that any testing that has sensitive information or requires specialized resources are
addressed suitably - when it becomes production ready.
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.**
Please check the answer to the user story #57.
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.**
Extending the answer to the user story #44 and user story #47, it is possible for Forgejo to implement templates for ticket submissions but cannot show already opened issue tickets with the similar verbiage to validate if the potential submission has already been proposed. The proposer needs to search for issue ticket by themselves before opening one.
Extending the answer to the user story #44 and user story #47, it is possible for Forgejo to
implement templates for ticket submissions but cannot show already opened issue tickets with
the similar verbiage to validate if the potential submission has already been proposed. The
proposer needs to search for issue ticket by themselves before opening one.
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.**
It is recommended to use the assignee section of a certain issue ticket and/or to tag the people involved in the action using their username. While this might not facilitate pings to be made to a certain user at equal intervals of time, it can very well be used to keep them posted about the updates made to the issue ticket and to inform them about their action items.
It is recommended to use the assignee section of a certain issue ticket and/or to tag the
people involved in the action using their username. While this might not facilitate pings to
be made to a certain user at equal intervals of time, it can very well be used to keep them
posted about the updates made to the issue ticket and to inform them about their action
items.
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.**
Please check the answer to the user story #8 and user story #9.

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

@ -9,64 +9,134 @@ User stories
Following is the investigation on GitLab based on the user stories collected.
1. **As a package maintainer, I'd like to be able to run my own CI jobs on distgit PRs.**
It is possible to run CI jobs (https://docs.gitlab.com/ee/ci/) on GitLab on certain events (like pushes or pull request creation). For specific purposes where a custom environment is required, even custom GitLab runners (https://docs.gitlab.com/runner/) can be associated with a certain project repository or project namespace.
It is possible to run CI jobs (https://docs.gitlab.com/ee/ci/) on GitLab on certain events
(like pushes or pull request creation). For specific purposes where a custom environment is
required, even custom GitLab runners (https://docs.gitlab.com/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.**
For this to work on GitLab, we would need to have metadata stored in repository. This could be
for example stored in `.metadata` file. Anybody with commit rights to repository will be able to
change the monitoring settings.
For this to work on GitLab, we would need to have metadata stored in repository. This could
be for example stored in `.metadata` file. Anybody with commit rights to repository will be
able to change the monitoring settings.
Or we can leverage GitLab badges feature (https://docs.gitlab.com/17.2/ee/user/project/badges.html)
which could be accessed by the-new-hotness through API and the maintainer can set the correct
monitoring badge for the project.
Or we can leverage GitLab badges
feature (https://docs.gitlab.com/17.2/ee/user/project/badges.html) which could be accessed by
the-new-hotness through API and the maintainer can set the correct monitoring badge for the
project.
3. **As a provenpackager, I should have push and merge access to all packages in the Fedora package collection.**
GitLab allows for a variety of roles (eg. guest, reporter, developer, maintainer, owner etc.) and binding of user accounts with these groups can ensure that the user accounts are provided with necessary permissions (https://docs.gitlab.com/ee/user/permissions.html).
GitLab allows for a variety of roles (eg. guest, reporter, developer, maintainer, owner etc.)
and binding of user accounts with these groups can ensure that the user accounts are provided
with necessary permissions (https://docs.gitlab.com/ee/user/permissions.html).
In this specific case, the proven packager group can be provided with the maintainer-level access so that they can have push and merge access to all packages available in the Fedora Project package repository while the releng-scm-bot can be provided with the owner-level access.
In this specific case, the proven packager group can be provided with the maintainer-level
access so that they can have push and merge access to all packages available in the Fedora
Project package repository while the releng-scm-bot can be provided with the owner-level
access.
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 has an experimental support for GitLab as long as the GitLab instance is publicly available and Packit is made aware about the identity of the instance by manually configuring webhooks at GitLab end using the steps provided in the docs (https://packit.dev/docs/guide#gitlab).
Packit has an experimental support for GitLab as long as the GitLab instance is publicly
available and Packit is made aware about the identity of the instance by manually configuring
webhooks at GitLab end using the steps provided in the
docs (https://packit.dev/docs/guide#gitlab).
The situation about the experiment support can change as soon as there are more stakeholders from Fedora Project requiring such support from the Packit's end, thereby making it a primary requirement from not just the CentOS Stream repository workflow but also for Fedora Project.
The situation about the experiment support can change as soon as there are more stakeholders
from Fedora Project requiring such support from the Packit's end, thereby making it a primary
requirement from not just the CentOS Stream repository workflow but also for Fedora Project.
5. **As a package maintainer, I'd like to have easy access links to Koji, Bodhi, and Koschei from the distgit repo.**
GitLab supports the use of badges (https://docs.gitlab.com/ee/user/project/badges.html) that provide a unified way of presenting condensed pieces of information about the project. 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.
GitLab supports the use of badges (https://docs.gitlab.com/ee/user/project/badges.html) that
provide a unified way of presenting condensed pieces of information about the project. 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/).
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, GitLab allows for a variety of roles (eg. guest, reporter, developer, maintainer, owner etc.) and it is also possible for the administrators (https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html) the customise the behaviours of these roles - thereby allowing for users who do not necessarily belong from the packagers group to be able to make pull requests to another project repository as long as the project repository is accessible to them.
As mentioned in the answer to the user story #3, GitLab allows for a variety of roles (eg.
guest, reporter, developer, maintainer, owner etc.) and it is also possible for the
administrators (https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html)
the customise the behaviours of these roles - thereby allowing for users who do not
necessarily belong from the packagers group to be able to make pull requests to another
project repository as long as the project repository is accessible to them.
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.**
GitLab provides for extensive customization of labels (https://docs.gitlab.com/ee/user/project/labels.html) and interweaving of issue tickets (https://docs.gitlab.com/ee/user/project/issues/related_issues.html) which can be used to denote circumstances where a certain issue ticket depends on another issue ticket and where a certain issue ticket is blocked on another issue ticket.
GitLab provides for extensive customization of labels
(https://docs.gitlab.com/ee/user/project/labels.html) and interweaving of issue tickets
(https://docs.gitlab.com/ee/user/project/issues/related_issues.html) which can be used to
denote circumstances where a certain issue ticket depends on another issue ticket and where
a certain issue ticket is blocked on another issue ticket.
8. **As a package maintainer, I'd like to continue to be able to use fedpkg to fork repositories and otherwise interact with distgit.**
GitLab provides with a comprehensive REST API (https://docs.gitlab.com/ee/api/rest/) that can be used to extend the GitLab 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 GitLab.
GitLab provides with a comprehensive REST API (https://docs.gitlab.com/ee/api/rest/) that
can be used to extend the GitLab 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 GitLab.
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, GitLab provides with a comprehensive REST API (https://docs.gitlab.com/ee/api/rest/) that can be used to perform actions that control all aspects of a pull request process (https://docs.gitlab.com/ee/api/merge_requests.html and https://docs.gitlab.com/ee/api/merge_request_approvals.html). This REST API can be included in command line tools for automation.
As mentioned in the answer to the user story #8, GitLab provides with a comprehensive REST
API (https://docs.gitlab.com/ee/api/rest/) that can be used to perform actions that control
all aspects of a pull request process (https://docs.gitlab.com/ee/api/merge_requests.html
and https://docs.gitlab.com/ee/api/merge_request_approvals.html). 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.**
Introducing Mergify! Mergify (https://mergify.com/) allows for automated merging of pull requests whenever a certain set of conditions are satisfied. The conditions for pull requests can be set as all CI jobs to complete successfully. Mergify also supports GitLab (https://docs.mergify.com/integrations/gitlab/).
Introducing Mergify! Mergify (https://mergify.com/) allows for automated merging of pull
requests whenever a certain set of conditions are satisfied. The conditions for pull requests
can be set as all CI jobs to complete successfully. Mergify also supports
GitLab (https://docs.mergify.com/integrations/gitlab/).
Alternatively, the inbuilt Auto-merge functionality (https://docs.gitlab.com/ee/user/project/merge_requests/auto_merge.html) of GitLab can be used for merging pull requests for which all the conditions satisfy. Even this has an REST API access for circumstances where tailor-fitting is required.
Alternatively, the inbuilt Auto-merge
functionality (https://docs.gitlab.com/ee/user/project/merge_requests/auto_merge.html) of
GitLab can be used for merging pull requests for which all the conditions satisfy. Even this
has an REST API access for circumstances where tailor-fitting is required.
11. **As a contributor, I want to be able to see who the current maintainer(s) are for a package.**
Project members associated with a certain GitLab project repository section can be found in the Project members section along with all necessary information like what level of access they have (eg. guest, reporter, developer, maintainer, owner etc.), the date of expiration of their access to the project (if set), the date of their user account creation, the date of their addition to the project repository or namespace, the date of the last access made by the user account etc. (https://docs.gitlab.com/ee/user/project/members/)
Project members associated with a certain GitLab project repository section can be found in
the Project members section along with all necessary information like what level of access
they have (eg. guest, reporter, developer, maintainer, owner etc.), the date of expiration of
their access to the project (if set), the date of their user account creation, the date of
their addition to the project repository or namespace, the date of the last access made by
the user account etc. (https://docs.gitlab.com/ee/user/project/members/)
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 #3, GitLab allows for a variety of roles (eg. guest, reporter, developer, maintainer, owner etc.) and it is possible for external collaborators to request for and for namespace/project collaborators to provide with these accesses as long as they are allowed to perform such actions.
As mentioned in the answer to the user story #3, GitLab allows for a variety of roles (eg.
guest, reporter, developer, maintainer, owner etc.) and it is possible for external
collaborators to request for and for namespace/project collaborators to provide with these
accesses as long as they are allowed to perform such actions.
The notification settings can be configured per repository without needing a prior permission of the owner or maintainer of the namespace/project to get informed about the activities taking place in a certain namespace/project repository (https://docs.gitlab.com/ee/user/profile/notifications.html).
The notification settings can be configured per repository without needing a prior permission
of the owner or maintainer of the namespace/project to get informed about the activities
taking place in a certain namespace/project
repository (https://docs.gitlab.com/ee/user/profile/notifications.html).
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 GitLab CI. Furthermore, the approval of a pull request can be associated with a GitLab webhook (https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) which in turn should trigger the normal builds. Although, conditional cancelling of jobs due to them being overriden by a more recent job is something that needs to be configured using the GitLab CI configuration but it is possible (https://docs.gitlab.com/ee/ci/yaml/).
Creation of a scratch builds based on the branch from which a pull request was created is
possible with the use of GitLab CI. Furthermore, the approval of a pull request can be
associated with a GitLab
webhook (https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) which in turn
should trigger the normal builds. Although, conditional cancelling of jobs due to them being
overriden by a more recent job is something that needs to be configured using the GitLab CI
configuration but it is possible (https://docs.gitlab.com/ee/ci/yaml/).
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.**
While this is a feature that can be created with the use of some intelligent parsing of the output taken from MDAPI (https://mdapi.fedoraproject.org/), the more elegant version of this implementation is unfortunately behind a paywall (https://docs.gitlab.com/ee/user/application_security/dependency_list/).
While this is a feature that can be created with the use of some intelligent parsing of the
output taken from MDAPI (https://mdapi.fedoraproject.org/), the more elegant version of this
implementation is unfortunately behind a
paywall (https://docs.gitlab.com/ee/user/application_security/dependency_list/).
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.
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.
@ -81,90 +151,197 @@ Following is the investigation on GitLab based on the user stories collected.
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://docs.gitlab.com/ee/user/profile/notifications.html) as long as they have an account in the said git forge solution.
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://docs.gitlab.com/ee/user/profile/notifications.html) 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.
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 GitLab 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 GitLab deployment intended for testing.
The set of JavaScript and WebAssembly tools involved in running a managed GitLab 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 GitLab 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, GitLab Community Edition is a free and open-source software. The repository of the project codebase can be found at https://gitlab.com/rluna-gitlab/gitlab-ce. There are certain parts of proprietary code involved in the said repository but there is also a pure FOSS variant of it available at https://gitlab.com/gitlab-org/gitlab-foss/ and the actual codebase available at https://gitlab.com/gitlab-org/gitlab. I suspect that there would be certain limitations in the pure FOSS variant but I cannot yet verify the same.
Licensed under the permissive MIT license, GitLab Community Edition is a free and open-source
software. The repository of the project codebase can be found
at https://gitlab.com/rluna-gitlab/gitlab-ce. There are certain parts of proprietary code
involved in the said repository but there is also a pure FOSS variant of it available
at https://gitlab.com/gitlab-org/gitlab-foss/ and the actual codebase available
at https://gitlab.com/gitlab-org/gitlab. I suspect that there would be certain limitations in
the pure FOSS variant but I cannot yet verify the same.
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://docs.gitlab.com/ee/user/project/protected_branches.html) of GitLab, one can ensure that changes to a certain set of branches can only be introduced using a pull request workflow.
With the use of Protected branches
mechanism (https://docs.gitlab.com/ee/user/project/protected_branches.html) of GitLab, 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).**
The specifics of the which set of users are restricted by the condition mentioned and the ones that are not can be set using the information found in the answer to the user story #3. According to the answer to the user story #6, this behaviour can be further customized by the administrators to ensure that the ones with the elevated privileges are left unrestricted.
The specifics of the which set of users are restricted by the condition mentioned and the
ones that are not can be set using the information found in the answer to the user story #3.
According to the answer to the user story #6, this behaviour can be further customized by the
administrators to ensure that the ones with the elevated privileges are left unrestricted.
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 the answer to the user story #1, as long as the GitLab CI is configured properly to support STI and TMT CI tests, they should work fine on GitLab like they do on Pagure - both in environments provided within the managed GitLab infrastructure and in custom GitLab runners introduced externally.
As mentioned in the answer to the user story #1, as long as the GitLab CI is configured
properly to support STI and TMT CI tests, they should work fine on GitLab like they do on
Pagure - both in environments provided within the managed GitLab infrastructure and in
custom GitLab 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 #23.
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.**
GitLab provides with the functionality of creating namespaces (https://docs.gitlab.com/ee/user/namespace/) that can have either multiple namespaces or project repositories associated with them. As long as the issue tickets are created for the project repository in a certain namespace or for the namespace in its entirety, they can be reassigned with other project repositories belonging to the same namespace.
GitLab provides with the functionality of creating
namespaces (https://docs.gitlab.com/ee/user/namespace/) that can have either multiple
namespaces or project repositories associated with them. As long as the issue tickets are
created for the project repository in a certain namespace or for the namespace in its
entirety, they can be reassigned with other project repositories belonging to the same
namespace.
28. **As a package maintainer, I want to be able to sync a fork with the upstream with a button click.**
GitLab user interface provides a nifty button for allowing folks to update their repository forks if they were to fall out of sync (https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#from-the-ui). Alternatively, people can rely on GitLab CI as mentioned in the answer to the user story #1 to automate the process by periodically updating a certain set of branches in their fork.
GitLab user interface provides a nifty button for allowing folks to update their repository
forks if they were to fall out of
sync (https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#from-the-ui).
Alternatively, people can rely on GitLab CI as mentioned in the answer to the user story #1
to automate the process by periodically updating a certain set of branches in their fork.
29. **As a package maintainer, I wish we had CI compatible with Github Actions.**
While GitHub Actions and GitLab CI are not inherently compatible with each other, they do work in a similar manner and there are a bunch of documentation that explain how one can migrate from GitHub Actions to GitLab CI conveniently (https://docs.gitlab.com/ee/ci/migration/github_actions.html).
While GitHub Actions and GitLab CI are not inherently compatible with each other, they do
work in a similar manner and there are a bunch of documentation that explain how one can
migrate from GitHub Actions to GitLab CI
conveniently (https://docs.gitlab.com/ee/ci/migration/github_actions.html).
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.
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.**
GitLab provides means to name, manage and protect Git branches according to a certain configuration (https://docs.gitlab.com/ee/user/project/repository/branches/#view-branches-with-configured-protections). This feature can be used to create branch with names following a certain regular expression pattern (eg. f39, f40, rawhide etc.) to protection while other branches might or might not be protected.
GitLab provides means to name, manage and protect Git branches according to a certain
configuration (https://docs.gitlab.com/ee/user/project/repository/branches/#view-branches-with-configured-protections).
This feature can be used to create branch with names following a certain regular expression
pattern (eg. f39, f40, rawhide etc.) to protection while other branches might or might not
be protected.
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).**
GitLab pays attention to established accessibility standards (https://docs.gitlab.com/ee/development/fe_guide/accessibility/) while the extent of support can be subjective in nature. It might be enough for a certain set of people with special needs while it might not be the same for others and hence, I propose further investigation on this from the Accessibility WG.
GitLab pays attention to established accessibility
standards (https://docs.gitlab.com/ee/development/fe_guide/accessibility/) while the extent
of support can be subjective in nature. It might be enough for a certain set of people with
special needs while it might not be the same for others and hence, I propose further
investigation on this from the Accessibility WG.
34. **As a package maintainer I'd like to be able to delete a wrong file from the look aside cache.**
As we are proposing the use of Git LFS (https://git-lfs.com/) for the storage of tarball archives and GitLab inherently supports it (https://docs.gitlab.com/ee/topics/git/lfs/), it should be as easy as pushing a file removal commit in order for deleting a previously added file to the lookaside cache. We understand that a similar set of changes also need to be introduced to fedpkg (https://pagure.io/fedpkg) in order to ensure that the commands associated with interacting with the lookaside cache play well with the Git LFS based solution.
As we are proposing the use of Git LFS (https://git-lfs.com/) for the storage of tarball
archives and GitLab inherently supports it (https://docs.gitlab.com/ee/topics/git/lfs/), it
should be as easy as pushing a file removal commit in order for deleting a previously added
file to the lookaside cache. We understand that a similar set of changes also need to be
introduced to fedpkg (https://pagure.io/fedpkg) in order to ensure that the commands
associated with interacting with the lookaside cache play well with the Git LFS based
solution.
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.**
As mentioned in the answer to the user story #7, the interweaving of issues is possible (https://docs.gitlab.com/ee/user/project/issues/related_issues.html) and these issue tickets can be exported out easily in the form of CSV (Comma Separated Values) files (https://docs.gitlab.com/ee/user/project/issues/csv_export.html) from the GitLab user interface as long as the user requesting for the export has at least the reporter access to the associated project namespace or repository.
As mentioned in the answer to the user story #7, the interweaving of issues is
possible (https://docs.gitlab.com/ee/user/project/issues/related_issues.html) and these
issue tickets can be exported out easily in the form of CSV (Comma Separated Values)
files (https://docs.gitlab.com/ee/user/project/issues/csv_export.html) from the GitLab user
interface as long as the user requesting for the export has at least the reporter access to
the associated project namespace or repository.
36. **As a package maintainer, I wish to have a Security tab listing known CVE, and dependencies known CVE for the package.**
While this is a feature that can be implemented with the use of Renovate (https://www.mend.io/free-developer-tools/renovate/) and GitLab support for Renovate (https://docs.renovatebot.com/modules/platform/gitlab/), the more elegant version of this implementation is unfortunately behind a paywall.
While this is a feature that can be implemented with the use of
Renovate (https://www.mend.io/free-developer-tools/renovate/) and GitLab support for
Renovate (https://docs.renovatebot.com/modules/platform/gitlab/), the more elegant version of
this implementation is unfortunately behind a paywall.
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.
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.
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://docs.gitlab.com/ee/user/project/repository/mirror/) is a feature available across multiple tiers of GitLab with the support for various Git forges for not only the contents of the Git repository but also the pull requests and issue tickets associated with it. One can also make use of GitLab CI (https://docs.gitlab.com/ee/ci/) to set a cronjob or event driven interaction.
Additionally, repository
mirroring (https://docs.gitlab.com/ee/user/project/repository/mirror/) is a feature available
across multiple tiers of GitLab with the support for various Git forges for not only the
contents of the Git repository but also the pull requests and issue tickets associated with
it. One can also make use of GitLab CI (https://docs.gitlab.com/ee/ci/) 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.**
GitLab provides issue trackers (https://docs.gitlab.com/ee/user/project/issues/) 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.
GitLab provides issue trackers (https://docs.gitlab.com/ee/user/project/issues/) 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 namespaces 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 namespace of the said packages are used.
Additionally, as mentioned in the answer to the user story #7, if the interweaving of the
issue tickets across various namespaces 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 namespace 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.**
GitLab provides some cool looking issue boards (https://docs.gitlab.com/ee/user/project/issue_board.html) that are blissfully unrestricted and available across various tiers. These issue boards follow the Kanban or Scrum methodologies for planning, triaging and implementing tasks associated with the namespace.
GitLab provides some cool looking issue
boards (https://docs.gitlab.com/ee/user/project/issue_board.html)
that are blissfully unrestricted and available across various tiers. These issue boards
follow the Kanban or Scrum methodologies for planning, triaging and implementing tasks
associated with the namespace.
These can be mixed and matched with the use of epics (https://docs.gitlab.com/ee/user/group/epics/), milestones (https://docs.gitlab.com/ee/user/project/milestones/) and issues (https://docs.gitlab.com/ee/user/project/issues/) to ensure that the progress reporting is verbose and effective in the software engineering process.
These can be mixed and matched with the use of
epics (https://docs.gitlab.com/ee/user/group/epics/),
milestones (https://docs.gitlab.com/ee/user/project/milestones/) and
issues (https://docs.gitlab.com/ee/user/project/issues/) to ensure that the progress
reporting is verbose and effective in the software engineering process.
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.**
While the roadmap feature (https://docs.gitlab.com/ee/user/group/roadmap/) is unfortunately behind a paywall, some intelligent use of the time tracking feature (https://docs.gitlab.com/ee/user/project/time_tracking.html) which is available across all the tiers should allow for us to have a similar effect of using a Gantt chart for tracking the various stages of the release process.
While the roadmap
feature (https://docs.gitlab.com/ee/user/group/roadmap/) is unfortunately
behind a paywall, some intelligent use of the time tracking
feature (https://docs.gitlab.com/ee/user/project/time_tracking.html)
which is available across all the tiers should allow for us to have a similar effect of using
a Gantt chart for tracking the various stages of the release process.
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 GitLab CI like the creation of scratch builds and actual buiilds can be controlled with the intelligent use of webhooks (https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) that GitLab 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).
As mentioned in the answer to the user story #13, the events possible with GitLab CI like
the creation of scratch builds and actual buiilds can be controlled with the intelligent use
of webhooks (https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) that GitLab
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.**
As mentioned in the answer to the user story #37, GitLab not only provides for issue trackers but also description templates (https://docs.gitlab.com/ee/user/project/description_templates.html) working on both issue tickets (https://docs.gitlab.com/ee/user/project/description_templates.html#create-an-issue-template) and pull requests (https://docs.gitlab.com/ee/user/project/description_templates.html#create-a-merge-request-template) that are available across all tiers for usage.
As mentioned in the answer to the user story #37, GitLab not only provides for issue trackers
but also description
templates (https://docs.gitlab.com/ee/user/project/description_templates.html)
working on both issue
ticket (https://docs.gitlab.com/ee/user/project/description_templates.html#create-an-issue-template)
and pull
requests (https://docs.gitlab.com/ee/user/project/description_templates.html#create-a-merge-request-template)
that are available across all tiers for usage.
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.
@ -173,64 +350,118 @@ Following is the investigation on GitLab based on the user stories collected.
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.**
GitLab shows related or similar issue tickets to the issue reporter based on the textual analysis (https://docs.gitlab.com/ee/user/project/issues/create_issues.html) of the issue content typed so far (both, head and description) in realtime without having to create the issue ticket first. This helps to ensure that the issue reporters are discouraged from reporting similar issue tickets if the same has been created before and instead they can be redirected to one of the existing ones to chime in.
GitLab shows related or similar issue tickets to the issue reporter based on the textual
analysis (https://docs.gitlab.com/ee/user/project/issues/create_issues.html) of the issue
content typed so far (both, head and description) in realtime without having to create the
issue ticket first. This helps to ensure that the issue reporters are discouraged from
reporting similar issue tickets if the same has been created before and instead they can be
redirected to one of the existing ones to chime in.
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.**
With the use of the milestones feature (https://docs.gitlab.com/ee/user/project/milestones/) of GitLab which is available across various tiers, it is possible to control the behaviour of the namespace based on an event associated with a milestone. Actions like creating, editing, closing and deleting a milestone have effect on the namespace and can be tailored to ensure that they meet the requirements intended for the namespace.
With the use of the milestones feature (https://docs.gitlab.com/ee/user/project/milestones/)
of GitLab which is available across various tiers, it is possible to control the behaviour of
the namespace based on an event associated with a milestone. Actions like creating, editing,
closing and deleting a milestone have effect on the namespace and can be tailored to ensure
that they meet the requirements intended for the namespace.
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.**
With the introduction of the Webhook To Fedora Messaging (https://github.com/fedora-infra/webhook-to-fedora-messaging/) project, webhooks (https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) on the platform can be integrated with the service to stay posted about the activities at the forge end.
With the introduction of the Webhook To Fedora
Messaging (https://github.com/fedora-infra/webhook-to-fedora-messaging/)
project, webhooks (https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) on the
platform can be integrated with the service to stay posted about the activities at the forge
end.
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.**
GitLab supports webhooks (https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) so as long as we are able to leverage the features with our existing CI pipelines - the service should be able to function similarly to the existing Pagure based git forge.
GitLab supports
webhooks (https://docs.gitlab.com/ee/user/project/integrations/webhooks.html)
so as long as we are able to leverage the features with our existing CI pipelines - the
service should be able to function similarly to the existing Pagure based git forge.
53. **As a contributor, I need to be able to login using my Fedora account.**
GitLab supports SAML (https://docs.gitlab.com/ee/integration/saml.html) and hence, plugging in support for authentication using a Fedora Account System account should be possible. This has been implemented to various degrees of success in the fedora namespace of the GitLab.com offering and hence, the same knowledge can be made use of in this implementation. This extends to group based access controls as well which means that Fedora Account System groups can be used to map access levels at the GitLab end.
GitLab supports
SAML (https://docs.gitlab.com/ee/integration/saml.html) and hence, plugging in support for
authentication using a Fedora Account System account should be possible. This has been
implemented to various degrees of success in the fedora namespace of the GitLab.com offering
and hence, the same knowledge can be made use of in this implementation. This extends to
group based access controls as well which means that Fedora Account System groups can be used
to map access levels at the GitLab end.
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.**
Being a free and open source software, we should be able to deploy multiple instances of GitLab with each instance having its own purpose and authentication backend without any issues.
Being a free and open source software, we should be able to deploy multiple instances of
GitLab with each instance having its own purpose and authentication backend without any
issues.
55. **As a maintainer of dist-git(s), I would like to use industry-standard tools to maintain large files.**
Please check the answer to the user story #34.
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.**
While I suggest rebasing and applying changes based on the review comments for a cleaner Git history, it is technically possible (https://docs.gitlab.com/ee/user/project/merge_requests/reviews/) for collaborators to apply the suggest changes with a click of a button on GitLab.
While I suggest rebasing and applying changes based on the review comments for a cleaner Git
history, it is technically
possible (https://docs.gitlab.com/ee/user/project/merge_requests/reviews/)
for collaborators to apply the suggest changes with a click of a button on GitLab.
57. **As a package maintainer, I would like to be able to automatically transfer issues between packages (for example from ansible -> ansible-core).**
This is fortunately possible in GitLab in a feature (https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#bulk-move-issues), that is blissfully unrestricted across various tiers of subscription. The transfers work without the restriction of the repositories having to belong under the same namespace.
This is fortunately possible in GitLab in a
feature (https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#bulk-move-issues),
that is blissfully unrestricted across various tiers of subscription. The transfers work
without the restriction of the repositories having to belong under the same namespace.
58. **A package maintainer, I would like a push hook to block pushes to retired or EOL branches**
GitLab supports Git Server hooks (https://docs.gitlab.com/ee/administration/server_hooks.html) which can be used to conditionalize the rejection of a pushed commit whenever they are made against a branch that is slated to be retired or EOLed. The presence of a documentation should make the process relatively convenient.
GitLab supports Git Server
hooks (https://docs.gitlab.com/ee/administration/server_hooks.html)
which can be used to conditionalize the rejection of a pushed commit whenever they are made
against a branch that is slated to be retired or EOLed. The presence of a documentation
should make the process relatively convenient.
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.**
It is possible to configure the access levels per branch dependent on certain branch names or branch names matching a certain pattern in GitLab. The feature is called "Protected Branches (https://docs.gitlab.com/ee/user/project/repository/branches/protected.html)" and is blissfully unrestricted across various tiers of subscription.
It is possible to configure the access levels per branch dependent on certain branch names
or branch names matching a certain pattern in GitLab. The feature is called "Protected
Branches" (https://docs.gitlab.com/ee/user/project/repository/branches/protected.html) and
is blissfully unrestricted across various tiers of subscription.
60. **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 (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.
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.**
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.
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.**
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.
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.**
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).**
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.
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.**
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).**
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.
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).**
Please check the answer to the user story #3 and user story #12.
@ -239,25 +470,44 @@ Following is the investigation on GitLab based on the user stories collected.
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
Certain continuous integration workflows can be associated to check for NVR changes
associated with a certain commit and following that the GitLab REST
API (https://docs.gitlab.com/ee/api/rest/) can be made use of to push tags to the
source repository. This can help with conveniently determining which commits were used to
create particular builds. This operation is involved more with the Git workflow so all kinds
of git forges should be able to do this.
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.**
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.
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.**
Please check the answer to the user story #70.
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).**
One can declare custom workflow configuration on GitLab CI (https://docs.gitlab.com/ee/ci/) in addition to the standard tests and builds (draft and actual) facilitated by Fedora Project. Furthermore, self proposed GitLab Runners (https://docs.gitlab.com/runner/) can also be registered to a certain project to ensure that any testing that has sensitive information or requires specialized resources are addressed suitably.
One can declare custom workflow configuration on GitLab CI (https://docs.gitlab.com/ee/ci/)
in addition to the standard tests and builds (draft and actual) facilitated by Fedora
Project. Furthermore, self proposed GitLab Runners (https://docs.gitlab.com/runner/) can also
be registered to a certain project to ensure that any testing that has sensitive information
or requires specialized resources are addressed suitably.
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.**
Please check the answer to the user story #57.
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.**
Extending the answer to the user story #44 and user story #47, it is possible for GitLab to implement templates for ticket submissions and show already opened issue tickets with the similar verbiage to validate if the potential submission has already been proposed. The proposer needs not search for issue ticket by themselves before opening one.
Extending the answer to the user story #44 and user story #47, it is possible for GitLab to
implement templates for ticket submissions and show already opened issue tickets with the
similar verbiage to validate if the potential submission has already been proposed. The
proposer needs not search for issue ticket by themselves before opening one.
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.**
It is recommended to use the assignee section of a certain issue ticket and/or to tag the people involved in the action using their username. While this might not facilitate pings to be made to a certain user at equal intervals of time, it can very well be used to keep them posted about the updates made to the issue ticket and to inform them about their action items.
It is recommended to use the assignee section of a certain issue ticket and/or to tag the
people involved in the action using their username. While this might not facilitate pings to
be made to a certain user at equal intervals of time, it can very well be used to keep them
posted about the updates made to the issue ticket and to inform them about their action
items.
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.**
Please check the answer to the user story #8 and user story #9.