As it currently stands, I like our EPEL stalled process procedure better, and unless they change the FESCo process, I say we do NOT remove ours.

Reasons Why:

• The longer two week period for the second request (making 3 weeks in total).
  -- We originally had just one week and maintainers complained because it was possible that they were on vacation for 2 weeks and came back to find someone had taken their package. Occasionally there was legitimate reasons why the package shouldn't go in EPEL.
• Requesting an approval from FESCo:
  -- Technically EPEL falls under FESCo. But why have an EPEL Steering Committee if everything goes through FESCo.
  -- I don't really want it going to the EPEL Steering Committee either. That just adds more time to the ticket, and more burdon to the Committee.
• Documentation:
  -- Our documentation has examples and is much more geared towards EPEL.
  -- Some of their documentation of what is needed before you do the request is better. I don't mind grabbing some of that.

There is also the matter that their process hasn't been "broken in". But even if we give it 6 months and several processes going through, if their process doesn't change, then my above arguments would still stand and I would not want to change.

I agree with Troy on pretty much everything here.

At least for the time being, I'd rather leave things as-is.

The longer two week period for the second request (making 3 weeks in total).

In practice I think the FESCo process will usually also work out to about 3 weeks total, as the FESCo ticket voting period is one week unless fasttracked. As an aside, I do like that their policy has a fasttrack option, so that would be a benefit of standardizing on the same policy.

I don't really want it going to the EPEL Steering Committee either. That just adds more time to the ticket, and more burdon to the Committee.

I mostly agree. I like that our policy is just "meet criteria". I don't think the FESCo vote requirement is overly burdensome, but I do think it's unnecessary. If this this ends up being the main sticking point on this becoming a shared policy, then we should see if FESCo is willing to drop that part.

Documentation:

I think the docs are a wash. Whatever we eventually decide on, we'll tweak the docs to match. That may be separate policies with docs to match, or a shared policy with docs that call out any EPEL differences as needed.

I agree with Troy. I think we should leave things as they are.

We discussed this at today's EPEL Steering Committee meeting.

I'll file a pull request to determine if FESCo is willing to drop the explicit vote portion of their process. After that is determined, ESC will revisit this.

https://pagure.io/fesco/fesco-docs/pull-request/110

Finally back from AFK, sorry, relocation took forever.

For context

• I initially made the trial FESCo process longer (similar to EPSco) and... was told that's too long. It's hard finding a balance
• The intention is to deprecate the EPSco process eventually, but I'd rather have this tested first before dropping the EPSco one
• I think if this works for FESCo (regardless of whether it works for EPSco too) we would likely want to revisit if the nuclear option (of orphaning everything a non-responsive maintainer holds) should be used. So something will change - either the trial process does not work, and need revising, or it works really well and we can reduce the scope of the full-blown process and direct people to the faster more lightweight process unless the maintainer in question is seriously non responsive.

Thanks for chiming in @salimma. That is pretty much what I remembered/expected.

I'll wait for feedback from FESCo on that docs PR proposal to drop the voting step.

In one of the ESC meetings I also agreed that I would take a package through the FESCo process to get a feel for it. I just don't have a candidate package for that yet.

The conclusion on fesco#110 was that FESCo still wants some approval, but is willing to relax it to just a single FESCo member ack in the releng ticket, avoiding the need for two separate tickets. I was going to adjust the PR to say that, but @zbyszek beat me to it and pulled my original commit into fesco#114 with an additional commit for the since ack change. That has been merged, so the next step is to use this process and see how it feels, then we can discuss if the separate EPEL process is still necessary.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/347

Please continue any further discussion there.