On Monday, March 1, 2021 10:44 AM, Johnny Hughes johnny@centos.org wrote:
On 3/1/21 9:44 AM, Matthew Miller wrote:
On Sat, Feb 27, 2021 at 01:18:46AM +0000, redbaronbrowser via CentOS-devel wrote:
CentOS now seems more receptive to greatly expanding the number of SIGs. Hopefully this will mean critical EPEL packages will migrate under CentOS. Once that has been done, it should be possible to get a more consistent CD/CI across both Stream and the Stream Extended packages inherented from EPEL.
Why duplicate? I'd rather see CentOS SIGs with interest in EPEL packages actually work in EPEL.
I would agree with this for items where you are trying to maintain the same versions. no ned to duplicate work.
If they need different versions for the SIG than are in EPEL .. maybe maintain those in the SIG.
How will CD/CI work across those lines?
For example, rsyslog depends on glibc, I assume a patch applied to glibc will also result in the CD/CI tests for rsyslog also being run. If the patch breaks rsyslog, the patch will be reviewed before release.
One of the concerns being brought up seems to be if the nature of Stream will break EPEL packages. As far as I see it, if CD/CI testing is integrated between the two then that concern should be addressed over time as testing continue to improve.
So, take for example, syslog-ng instead of rsyslog. Is there any method for that package to also trigger CD/CI tests for glibc changes while remaining in a repo that is technically external to Stream?
If Stream 8 could have a change which breaks EPEL 8 packages, couldn't that indicate an API/ABI break which could create larger issues if ever propigated into RHEL?
To be clear, I'm not asking if Stream 9 might break EPEL 8 packages. I'm also not asking how quickly EPEL 9 will be available after the release of Stream 9. I'm just asking how CD/CI testing will work across like versions (Stream/EPEL 8, Stream/EPEL 9, etc).