Bug 1127715 - RFE: Add support for group projects
Summary: RFE: Add support for group projects
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Copr
Classification: Community
Component: frontend
Version: unspecified
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-07 11:52 UTC by Nikolai Kondrashov
Modified: 2015-10-15 11:09 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-15 09:45:51 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1261801 None None None Never

Internal Links: 1261801

Description Nikolai Kondrashov 2014-08-07 11:52:38 UTC
Currently Copr only supports projects tied to a particular Fedora Account.
URLs of repositories of these projects contain the account's name.

It might be beneficial to make Copr support projects tied to Fedora Account
Groups, so software projects can have common repos not tied to a particular
developer, but rather to the project itself.

One use case could be this: the sssd project needs a repo to host packages of
some new dependencies for supplying a CI system running builds on already
released distros, which don't have them. Such repos would need to
be added to configurations of developer machines so local CI builds can
install the dependencies.

In case this Copr project owner wishes to stop maintaining it for whatever
reason, the project will need to be re-created under a different account and
the CI server and all the developer configurations will need to be updated,
which is cumbersome and produces service and thus development process
interruption.

One way to implement this could be to provide Fedora account group
administrators a way to select (their own) user or a group account under which
the Copr project should be created on the "Add a new Project" form.

Additionally, to match this change, the permissions system may be extended to
provide a way to grant permissions to groups, but this would be of lower
usefulness as likely only a few people are usually granted modification
access to Copr projects. Otherwise the existing model of granting permissions
to particular users should be sufficient in most cases.

Comment 1 Igor Gnatenko 2014-08-07 12:20:26 UTC
I think other option can be let adding groups to access management (permissions in webUI)

Comment 2 Nikolai Kondrashov 2014-08-07 12:38:05 UTC
Igor, this would still leave the owner's account name in the URL, which would be very nice to avoid.

Comment 3 Haïkel Guémar 2015-07-08 09:44:05 UTC
I still see value in mapping FAS groups to "virtual" users in copr.
A practical use case is openstack packaging, we're now reusing my fellow packager Jakub account to create our repositories.
Advantages:
* no SPOF, any group member would be able to create repositories in the same namespace.
* centralized group membership (in FAS) instead per repo
* proper branding

Comment 4 Orion Poplawski 2015-07-15 16:37:01 UTC
We really need this.  e.g. KDE COPR for EPEL7 really needs more people working on it other than Rex.

Comment 5 Radek Holy 2015-09-01 15:37:46 UTC
We would appreciate this in DNF as well since we would like to host our nightly builds in COPR.

Comment 6 Miroslav Suchý 2015-10-15 09:45:51 UTC
Version with this fix has been just deployed to production.

Comment 7 Nikolai Kondrashov 2015-10-15 11:09:48 UTC
Thanks a lot, Miroslav!


Note You need to log in before you can comment on or make changes to this bug.