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

Add answers to three new user stories

Browse source 
Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com>
This commit is contained in:
Akashdeep Dhar 2024-11-04 11:53:29 +05:30
parent 8f97caaa4b
commit 1100b5be43
3 changed files with 39 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -518,3 +518,17 @@ Following is the investigation on Forgejo based on the user stories collected.
90. **Upgradability - User Story: As a SaaS administrator, I want to safely apply database schema upgrades without causing outages or data loss.**
Forgejo can be upgraded, https://forgejo.org/docs/latest/admin/upgrade/
91. **As a maintainer of packages in Fedora, I would like the ability to move a ticket assigned to my project to a new project. As an example, . I get a few tickets every month against "fedora-release" because people just use that as a stand-in for "I don't know what package to report against"**
Please check the answer to the user story #27.
92. **As a Fedora CI maintainer, I would like to have the ability to enable mandatory checks for each dist-git pull request to ensure Fedora distribution stability.**
Please check the answer to the user story #10.
93. **As a Fedora forge administrator, I would like to have legally-enforceable assurances that features available in the open-source (or "community edition") of the forge will remain that way in the future in order to prevent platform decay from degrading the functionality.**
While Forgejo might not have a versioned documentation due to it being relatively less
mature than GitLab, it does not seem to have an enterprise offering. While we can ensure
that it will stay this way going forward - it is less likely for the platform decay to
take place when there is no separate community and enterprise edition. Although, just like
GitLab, it is difficult to legally enforce the prevention of such a thing, should it
happen at some point in time and while there would be a community backlash about the same,
we will be left with not much power to do something about this.

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

@ -589,3 +589,19 @@ Following is the investigation on GitLab based on the user stories collected.
https://docs.gitlab.com/ee/update/?tab=Helm+chart+%28Kubernetes%29#upgrade-based-on-installation-method
and migrations also likely required to be carried out see
https://docs.gitlab.com/ee/update/background_migrations.html
91. **As a maintainer of packages in Fedora, I would like the ability to move a ticket assigned to my project to a new project. As an example, . I get a few tickets every month against "fedora-release" because people just use that as a stand-in for "I don't know what package to report against"**
Please check the answer to the user story #27.
92. **As a Fedora CI maintainer, I would like to have the ability to enable mandatory checks for each dist-git pull request to ensure Fedora distribution stability.**
Please check the answer to the user story #10.
93. **As a Fedora forge administrator, I would like to have legally-enforceable assurances that features available in the open-source (or "community edition") of the forge will remain that way in the future in order to prevent platform decay from degrading the functionality.**
GitLab has versioned documentation, the archives https://docs.gitlab.com/archives/ of
which go as far back as GitLab 10.3. These documentation draw a line between what is provided
in the free-of-cost community edition and what can be made available using the ultimate
edition. As these documents can be made available to be downloaded locally to as a container,
we can be very sure that the if there are any platform decay that takes place. Although, it
is very likely not legally enforceable and should they do something like this, this might end
up causing a backlash in the community but with not much power on our hand to be able to
reverse such a change.

9
docs/dist-git-comparison/stories.rst
View file

@ -277,3 +277,12 @@ Following is the investigation on GitLab based on the user stories collected.
90. **Upgradability - User Story: As a SaaS administrator, I want to safely apply database schema upgrades without causing outages or data loss.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-935325>`_ by **David Kirwan** (``dkirwan``)
91. **As a maintainer of packages in Fedora, I would like the ability to move a ticket assigned to my project to a new project. As an example, . I get a few tickets every month against "fedora-release" because people just use that as a stand-in for "I don't know what package to report against"**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-938939>`_ by **Stephen Gallagher** (``sgallagh``)
92. **As a Fedora CI maintainer, I would like to have the ability to enable mandatory checks for each dist-git pull request to ensure Fedora distribution stability.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-939901>`_ by **Miroslav Vadkerti** (``mvadkert``)
93. **As a Fedora forge administrator, I would like to have legally-enforceable assurances that features available in the open-source (or "community edition") of the forge will remain that way in the future in order to prevent platform decay from degrading the functionality.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-940420>`_ by **Stephen Gallagher** (``sgallagh``)