sdgathman asked me to build nacl for epel, I wanted to create the branches, I went to the pkgdb, noticed that sdgathman requested the branches there, I approved the request and I thought I will have the commit rights, but I hadn't. The current process seems quite broken to me.

You have commit on all branches except epel7 and similarly you have approveacls on all branches bug epel7. Which means you can only add/remove ACLs on all these branches.

The request for the epel7 branch was from sdgathman so, when it got approved, sdgathman got the ACLs on that branch. This is working as intended as quite often the person requesting a EPEL branch might not be the person already maintaining the package in Fedora and there are quite a few Fedora maintainers who are happy to have someone else maintain in EPEL.
The validation step is basically only required to allow the Fedora maintainer to deny a branch request if there is a reason for which a branch should not be created (package is in rhel, won't work, conflicts...).

So while everything you described is basically how things should be working. Is there a way we could have made it clear(er) ?

Sorry, I still think it's broken, you wrote:

This is working as intended as quite often the person requesting a EPEL branch might not be the person already maintaining the package in Fedora and there are quite a few Fedora maintainers who are happy to have someone else maintain in EPEL.

This is exactly my case and I ended with no commit rights to the branch which I am OK to maintain. So, how it is supposed to work? There was no sign in the request I was approving "you will not have commit rights after", there is also no info saying what to do to have commit rights. This is at least very confusing. So we ended with person who probably do not want to maintain the package having commit rights and with person (me) who acked the request, expressed willing to maitain the package in the EPEL-7 branch and not having the commit rights. Strange! If it is the way how it is supposed to work, it's seriously broken, and the process should be rethink.

Requesting a branch in pkgdb is requesting the branch, it's not asking someone to maintain the package. Requesting the branch in pkgdb is very much: I want to maintain this branch and if it's an EPEL branch the Fedora maintainers are given the possibility to agree or not on this branch being created, but if they are not the ones requesting it, they are basically saying: we agree with you having this branch.

So what you approved was his/her request for the branch, you didn't ask for it.

Now if you want commit on that branch, simply ask the person who has approveacls on it, so sdgathman.

Do note that I am not saying that the process cannot be changed or improved, I am merely explaining its current status. Actual suggestions (ie not it's seriously broken) are welcome.

Sorry, but it is broken and I suggested concrete thing how to improve it: i.e.

• write there a message what the maintainer is approving and maybe
• write there a message what the person is requesting

Just doing some ad-hoc deductions what it is all about isn't good. Imagine the following situation:

• person (not current maintainer) wanted the branch (doesn't want to maintain it)
• he saw the button request branch
• so he requested it
• maintainer saw the request and now what to do?
  a) deny the request and create his own request? this is not written anywhere
  b) approve the request and add his own request to have the commit rights? this is even more confusing

I had several requests in the past which I had to deny because the persons were asking for EPEL branches for packages which already existed in RHEL. So I thought approving it means: maintainer is OK with the branch for being created, NOT maintainer is giving up on this branch.

Hope you see the problem.

Or maybe:

add there checkbox to the request approval stating whether the maintainer wants to be also added to the package.

I disagree that it's currently broken, but I do believe that things could be explained better.

So, I definitely think we could adjust here, but not fully sure how.

The problem is that we are overloading the "request new branch" when someone is not the maintainer. It could mean:

• They want to maintain this and would be happy to do so alone.

• They want to maintain this and would be happy to do so with the rest of the maintainers of the package.

• They want the branch, but don't want to maintain it at all, they want existing maintainers to.

Do we currently check if the requester of a new branch in pkgdb is a packager? Or anyone can request?

If we do not allow non packagers to request new branches, then the last case is mostly handled and perhaps we just need more info on the request a branch page about that.

The first two cases I guess we would need to decide if we add an option or go one way or the other.
ie, we could:

• automatically grant co-maintainers perms on the new branch (they can remove if they don't want them)

• just grant the requestor the new branch perms (co-maintainers can request if they want them) I guess this is what we have now.

• make 2 options "branch with comaintainers" or "branch with no comaintainers"

Do we currently check if the requester of a new branch in pkgdb is a packager? Or anyone can request?

We do :)

just grant the requestor the new branch perms

This is the current situation indeed.

I think I kinda like the idea of an Approve and Add me state. My current thinking was that maintainers would just work it out together and the one getting approveacls would grant ACLs to the other(s).

Guys, thanks to follow up on this.

I think just adding the existing maintainers to the package should be harmless. They could drop their rights anytime or just ignore them and do not touch the branch. Also this way they could check and help the new maintainer more easily in the beginning.

I'm fine with that... any differing thoughts?

Ok, I've opened an issue upstream so we can close this ticket for now: https://github.com/fedora-infra/pkgdb2/issues/401