On Mon, Jul 02, 2018 at 02:03:19PM -0400, Stephen John Smoogen wrote:
On 2 July 2018 at 13:54, Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jul 2, 2018 at 11:14 AM Matthias Runge mrunge@matthias-runge.de wrote:
It's quite easy to get a package into EPEL. We all know, it happens from time to time, that packages there get upgraded at times you don't really like, especially when that breaks your CI.
I don't want to sound too rude here, but have you tried actually being involved in the maintainership of those packages in EPEL that you need?
I believe Mathias has worked on various parts of EPEL and other repositories for a long time. His frustration with things changing out from underneath him in EPEL several times are quite valid. I don't think that there is going to be one answer to fixing this, but there may be methods that it can be done to make it less frustrating.
An explosion of SIGs also causes its own burdens, and things that are common to multiple SIGs probably should be in EPEL so that maintenance is shared and used by everyone.
I'm in contact especially with the fine folks maintaining qpid and proton in EPEL. Having the SIG does not mean, the packages from EPEL need to go away. Since I need the packages being included in a buildroot on the centos build system, I believe, this discussion doesn't get us far.
Ideally, we'll catch regressions before packages are being pushed to any repository. I'd like a tighter integration in CI systems like with RDO CI.
Re: explosion of SIGs, I hope you mean the explosion of number of SIGs ;-)
We have currently the unfortunate situatuation with ansible, for example. It is used/built/consumed in multiple SIGs, and then cross-tagged to others. With Ansible, we don't have linking issues, when you're using multiple different versions of the same package.
In my opinion, Having a number of SIGs with a clear and defined focus will probably help us more than having a single repository with mixing all stuff together.
Matthias