#8844 Nonmaintainers can request branches
Closed: Fixed by kevin. Opened by churchyard.

  • Describe the issue

When a Fedora contributor requests a branch (such as epel8), nothing checks whether they actually are maintainers of said package.

See for example https://pagure.io/releng/fedora-scm-requests/issue/17212

While this doesn't override any "security" (they cannot push to that branch), it can create confusion (they cannot push to that branch).

This is clearly not a good thing. The acls should be required.

  • When do you need this? any time

  • When is this no longer needed or useful? once the workflow changes

  • If we cannot complete your request, what is the impact? empty epel8 branches, confused contributors


Then we should clearly disallow creating of branches if the request is coming from someone who is not a maintainer of the package.

Metadata Update from @mohanboddu:
- Issue assigned to mohanboddu

https://pagure.io/fedscm-admin/pull-request/20 should fix this.

Provenpackager can do that without asking?

They should not be able to IMHO.

If there is some rare case where a package needs branched urgently to fix something, it can be requested via releng.

OK.
But if maintainer not answer to bugreport about it and epel8 branch need to build other package?

Fedpkg request it via releng or not?

Sure, there does need to be some generic timeout after waiting X time to get the branch anyhow... I suppose the tool could check the creation time of the request?

This feels to me like we're taking away even more functionality that we used to have with the old pkgdb system.

If the main concern is user confusion, can we simply print a warning in the fedora-scm-requests ticket instead of rejecting it outright?

I think the main concern is people requesting branches for epel and pushing some initial build then wandering off and leaving the existing maintainers holding the bag for work they didn't sign up for.

If we force people to become co-maintainers and maintain the thing that they are requesting, that removes the work from the other maintainers.

I think branches should only be able to be requested by maintainers, but I also think that perhaps requesting a branch by a non-maintainer should automatically make that person a maintainer. I know this moves us even farther from the "owner" model - but I think that's a good thing.

I like that idea @orion .

I'm not sure I like that too much... why is it so difficult to just talk to the existing maintainer(s)? This would bypass them and potentially branch things that are not maintainable... but if the requestor just asked the existing maintainers could explain why it might be a bad idea, etc.

Yeah, that's definitely preferable. But I would say the majority of the EPEL8 branch/build BZ requests that I have filed have gone unanswered. But perhaps fedpkg request-branch could take a --bz option to point to such requests to show that a request was made.

Yeah, that's definitely preferable. But I would say the majority of the EPEL8 branch/build BZ requests that I have filed have gone unanswered. But perhaps fedpkg request-branch could take a --bz option to point to such requests to show that a request was made.

At least in my case, I'm swamped with requests. People are asking for EPEL8 branches for almost everything I maintain or co-maintain. I have to make judgements for each one, and since EPEL 8 isn't quite filled out yet, I also have to figure out how hard each one is going to be.

The reason I don't prefer "contact the maintainer directly" is that those private email discussions don't happen in a public forum. It's important for Fedora's growth to make it easy for people to see what other people are doing. Private emails don't radiate information like public tools do.

I think branches should only be able to be requested by maintainers, but I also think that perhaps requesting a branch by a non-maintainer should automatically make that person a maintainer. I know this moves us even farther from the "owner" model - but I think that's a good thing.

In the days of pkgdb that use to be the case, any approved packager could request a branch (I don't remember if there was an approval process by the package admin, I think there was and if it was it just happened), but they were made the owner of that branch and got all the bugs assigned to them. This is definitely a reduction in functionality from the old system.

This was merged and is active. If we want to change it's behavior now I guess open a new ticket?

I agree private emails/talk is not great, I think the alternative would be to file a bug and track it there?

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Metadata