Add 10 more answers to user stories
Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com>
This commit is contained in:
parent
88ea372eac
commit
1a7c0cea77
2 changed files with 20 additions and 20 deletions
|
@ -181,34 +181,34 @@ Following is the investigation on GitLab based on the user stories collected.
|
|||
Please check the answer to the user story #7.
|
||||
|
||||
51. **As a consumer of the fedora messaging bus, I want to be able to continue to receive messages in a JSON format on events.**
|
||||
UNRESOLVED
|
||||
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.**
|
||||
UNRESOLVED
|
||||
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.**
|
||||
UNRESOLVED
|
||||
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.**
|
||||
UNRESOLVED
|
||||
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.**
|
||||
UNRESOLVED
|
||||
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.**
|
||||
UNRESOLVED
|
||||
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).**
|
||||
UNRESOLVED
|
||||
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**
|
||||
UNRESOLVED
|
||||
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.**
|
||||
UNRESOLVED
|
||||
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.**
|
||||
UNRESOLVED
|
||||
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.**
|
||||
UNRESOLVED
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue