#1408 New package/branch request processes (off bugzilla to pkgdb)
Closed None Opened 9 years ago by pingou.

Dear FESCo members,

Discussing with rel-eng, we thought it would be a good idea to move the process
of requesting a package to be added to Fedora (after review) and the process of
requesting a new branch for an existing package, from bugzilla to pkgdb.

The full discussion and the progress can be seen at:
https://fedorahosted.org/rel-eng/ticket/5931
I have also been presenting the workflow for new branch requests on my blog:
http://blog.pingoured.fr/index.php?post/2015/01/22/New-branch-request-process

During the code review, one potential issue popped-up for which I would like more
input.

With the current process in pkgdb, requests for new Fedora branches are
automatically approved. This means, packager X can request a branch for F19 and
get it automatically while the packager Y that added the package to Fedora
explicitely did not want it (because for some reasons it does not work).

Since one can only request a branch for himself/hershelf there could be no
problem, packager X is point of contact for F20+ and packager Y for F19.
However, this will not hold as bugzilla only accept one point of contact per
component per product (Fedora), no matter the version of the product (F20, F19...)
So Packager X would get assigned to the bugs opened against the version 19 even
though packager X is not the point of contact for that branch.

I see several options to deal with this situation:
* Let it be the way it is
{{{
+ Less work for rel-eng
+ No need to wait on anyone to get things done in Fedora
- Packager X will get bugs for a branch he/she is not the PoC for
Note: Packager X can re-assign the bugs to Packager Y in bugzilla
}}}
This basically assumes our packagers are smart enough to communicate between
themselves before making a decision (ie: Q: I need this packager in F19, shall I
ask for the branch myself or do you want it? A-1: There is no problem go-ahead;
A-2: Unfortunately this package won't work on F19 for XYZ reasons)

  • Implement a similar waiting period for Fedora branch as we do for EPEL branch
    requests

So for EPEL branch requests, when a requests is made, its status is Pending.
During 7 days after the request was opened, the packager with approveacls on the
package can set the status to either 'Blocked' or 'Awaiting Review'. If they
block the request they will have to provide an explanation (Won't work because
of XYZ reasons). Marking the request as 'Awaiting Review' flags it as ready to
be processed/reviewedd by rel-eng.
After these 7 days, requests that are 'Pending' automatically switch to 'Awaiting
Review', so if the packager was not interesting to react, we let rel-eng process
the request.

{{{
+ Give 7 days to the current package admins to approve/block the request
- More work on rel-eng that will have to process these requests
- Need to wait at max 7 days + x (being the time for a rel-eng to process the
queue)
}}}

As these are changes to the current process, I would like to hear FESCo's opinion
about the changes in general and about the question of the Fedora branches in
particular.

Thanks for your attention.


We didn't get to this today, but adding the meeting keyword so it gets added to the next meeting.

Bugzilla's emails give you enough headers to know what Fedora version the bug is against, so I'd prefer to leave it as it is. The scenario seems rare enough, and can already be handled on the client side.

This ticket will be discussed in the FESCo meeting on Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

I'm for doing the second proposal... that if someone who doesn't have acls for a package requests a new branch, it waits a week for feedback from the current maintainers.

I think this would prevent well meaning but inexperenced folks from requesting branches where there are reasons for them not to be there.

From today’s FESCo meeting: Implement a similar waiting period for Fedora branch as we do for EPEL branch (+5)

Ok, thanks for your input I will adjust accordingly.

Two follow-up questions though
Does this apply if the user requesting the branch already has approveacls on one of the other branch? (ie: If I request a Fedora branch for a package that I already maintain, should it be set to Pending by default or be automatically approved?)
If yes to the first one (request set as Pending), should I prevent the person that requested the new branch to be able to review and approve (ie: Set to Awaiting Review) it before the 7 days have passed? (thus making the 7 days period mandatory on packages that have only one maintainer)

Let’s try to resolve this in the ticket…

Replying to [comment:6 pingou]:

  • Does this apply if the user requesting the branch already has approveacls on one of the other branch? (ie: If I request a Fedora branch for a package that I already maintain, should it be set to Pending by default or be automatically approved?)
    My vote is to auto-approve in this case.
  • If yes to the first one (request set as Pending), should I prevent the person that requested the new branch to be able to review and approve (ie: Set to Awaiting Review) it before the 7 days have passed? (thus making the 7 days period mandatory on packages that have only one maintainer)
    … which makes this not applicable.

please auto-approve, we don't want same user to wait.

I'm inclined to say that anyone with ''commit'' access (not just approveacls) should be auto-approved for creating a new branch. If they have commit access, it can be reasonably assumed that they know enough about the package to port it to another release.

Login to comment on this ticket.

Metadata