On Thu, Jun 24, 2021 at 4:32 PM Troy Dawson <tdawson@redhat.com> wrote:
>
> During our last round of proposals for solutions to missing devel packages, it was noted that EPEL and CentOS has very different documentation for requesting a package be put into RHEL 8.[1][2]
>
> I am betting that CentOS's documentation is correct.  It was written after ours.
>
> When I was talking to the Red Hat people who know, it was noted that Red Hat has much better communication with the Fedora and CentOS communities than the EPEL community.[3]  They wanted to start fixing that communication gap, and figured this would be a good way to start.  So I'm asking Josh Boyer to answer this question on behalf of Red Hat.

Thanks, Troy!

> How would Red Hat like us, EPEL maintainers and developers, to request missing devel packages?  (devel packages that are built at the same time as a released library in RHEL8, but not released in RHEL8.  Such as lmdb-devel)

The process as documented on the CentOS wiki page is the best route.
Filing a bug against the package in the Red Hat Enterprise Linux
product family with the CentOS Stream version set will ensure that
both the team maintaining the package in RHEL and some from the CentOS
Stream team are looped in.  Getting the request in front of the owning
RHEL team is key, as they will need to evaluate the request and
consider the implications of providing the devel package.

I would like to make sure and clarify that this is the best approach
for devel packages from SRPMs that are already part of RHEL.
Completely new package requests for things that are not in RHEL at all
are RFEs that should likely come through a case filed in the Customer
Portal for those that have a valid subscription.

> If we follow Red Hat's procedure, what are the odds that the package will make it into RHEL 8 CRB?

This one is harder to answer in a general sense.  I don't want to be
misleading, so I won't give odds because it will vary depending on the
package.  I'll certainly say the odds are better if the requests are
made than if they aren't :)  We have grown the CRB content set by over
100 packages since the initial RHEL 8.0 release, and continue to add
packages even today.  I'd like to also describe some of the
considerations at play as we work on this.

Essentially, the team that owns the package will evaluate the request
to ensure it's consistent with the manner in which the package is
intended to be used as part of RHEL.  Often enabling other software to
build against a RHEL package, particularly for things like EPEL
enablement, is a perfectly valid use case.  Once a valid use case has
been established the team will ensure they can meet any obligations
required by adding it as part of the RHEL product and sign off.  After
the team has agreed, the package will first appear in CentOS Stream
PowerTools (or occasionally AppStream), and then in a future RHEL
minor release.

At times, we have included a library or package as an internal
implementation detail and do not encourage wider use of that package
for other software.  This is a relatively rare case.  I can only think
of one stand-out package that comes to mind thus far.  If it does
happen the team may decide not to provide the devel package.  Filing
the request is often the best way to begin that dialog.  This helps us
understand how a package is being used and take that into
consideration for future RHEL releases, and also allows discussion and
suggestions for alternative packages that may be more suitable in the
long term.

I'm sure there are many that would simply like all subpackages of all
SRPMs to be shipped, however that is not the approach RHEL is taking
from a product perspective.  Blanket requests for everything are not
likely to go far.  It's simply not actionable at the same level as
targeted requests.

As an aside, I am particularly encouraged to see EPEL-Next come to
fruition and combined with CentOS Stream and the broader set of
packages available in that project buildroot I think there is a lot of
potential to grow the overall ecosystem.  I believe EPEL has discussed
this recently with some hesitation, but I would encourage you to
consider if and how EPEL-Next and CentOS Stream might be leveraged to
help EPEL proper as well.  From what I've seen, this community is
amazing and I think there are opportunities there.

Thanks again Troy, for giving me the opportunity to interact with the
EPEL community.  This is quite overdue.

josh