Unfortunatly we are not able to create groups that can be used only in the tests namespace, so you will have to get a regular dist-git group, which comes with some requirements.

We've documented the different groups available in Fedora at: https://pagure.io/fedora-infra/howtos/blob/master/f/groups_in_fedora.md
Please have a look at it, as we will need some more information from you to process this request.

Thanks @pingou,
I think that the description best fits the pkgdb group. The only problem I see is that some of the people in the group are not in the packager group. The group would consist of package maintainers and a couple of QE, but QE usually don't have a sponsorship because they don't maintain any packages so they are not part of packager group.

On the other hand, I only need this to manage access to the tests/* namespace, I don't want to extend this to any package, just the tests.

Not sure about the mailing list though, I understand that it is mandatory to create one together with the group?

Thanks,
Michal

So the issue is that there are no distinctions between groups. Once a group is created, it can be given commit access to all projects in the tests/ namespace, but also to any project in the rpms/ namespace or the modules/ namespace and everyone who is committing to these namespaces must be in the packager groups. Thus the requirement for pkgdb group to require the packager membership.

(A side note: only packagers have ssh access to dist-git, so the non-packager members of the group will have to push via https - just something to keep in mind :))

Not sure about the mailing list though, I understand that it is mandatory to create one together with the group?

Technically it is, although in this case, since the projects in the tests/ namespace are not synced to bugzilla, we can likely make an exception. It will break things if the group is ever added to a non-tests project but we (infra) will be warned about it.

(A side note: only packagers have ssh access to dist-git, so the non-packager members of the group will have to push via https - just something to keep in mind :))

So this means that even a non-packager can be part of the group? If they are ok with pushing stuff via https?

(A side note: only packagers have ssh access to dist-git, so the non-packager members of the group will have to push via https - just something to keep in mind :))

So this means that even a non-packager can be part of the group? If they are ok with pushing stuff via https?

Yes and this is the core of the issue since if the group was added as a maintainer of a package in the rpms or modules namespace, all of its members would have access to the package without being packager.

I see, well there are those who said that they will give our QE sponsorship for this purpose if needed but I am not sure if that is the right way to do this. Do you mind if I raise this question on fedora-devel? It might actually spark an interesting discussion.

Do you mind if I raise this question on fedora-devel? It might actually spark an interesting discussion.

Not at all.

Whats the status here? There was a post on devel, with one reply (which wasn't really following what the question was I don't think?)

As I see it, ways forward:

• Just add these QE folks to 'packager' and make the group like normal.

• Don't add QE folks to 'packager' and if they try and use ssh to push anything, they will know it shouldn't work and they would need to use https

?

Any thoughts on the ideas in the last comment?

Whats the status here? There was a post on devel, with one reply (which wasn't really following what the question was I don't think?)

As I see it, ways forward:

• Just add these QE folks to 'packager' and make the group like normal.

That may be the simplest from our perspective

• Don't add QE folks to 'packager' and if they try and use ssh to push anything, they will know it shouldn't work and they would need to use https

That would work but would give people commit access (via http) to a package if
the group is added to a project.

In both cases the QE folks can/could get commit access to packages.

Hi, sorry for long silence here. The answer on devel-list wasn't so far off was it? Let the QE person become a co-maintainer of said package would allow them to get into the packager group.

But in all three cases we are still dealing with the fact that QE guys would have access to packages the way that packagers do.

But at least with the co-maintaining, the actual owner of the package can teach the QE counterpart what to do and even in the main repo, there are files important for testing that need a change from time to time...

Let the QE person become a co-maintainer of said package would allow them to get into the packager group.

If that is the preferred approach, I'm all for it. It also means this ticket is no longer valid, no?

But in all three cases we are still dealing with the fact that QE guys would have access to packages the way that packagers do.

I think we're fine with it as it is an "explicit" access, the original worry was around people getting access "by accident" (e.g: someone giving commit access to a group without realizing that the people in this group are not packagers). With the approach described above, QE engineers become regular packagers and there is no risk or giving them more access by accident.
(Not entirely sure if I make sense there, do I?)

Let the QE person become a co-maintainer of said package would allow them to get into the packager group.

If that is the preferred approach, I'm all for it. It also means this ticket is no longer valid, no?

Is that correct?

Yes, we can close this. Thank you all for the discussion here, it really helped.

Regards,
Michal