On 2 July 2018 at 11:14, Matthias Runge <mrunge at matthias-runge.de> wrote: > On Mon, Jul 02, 2018 at 03:33:06PM +0100, Trevor Hemsley via CentOS-devel wrote: >> On 02/07/18 13:36, Matthias Runge wrote: >> > Creation of a new SIG "Messaging" >> > ================================= >> > >> > Hereby, I'm asking for comments about founding a new SIG to handle >> > messaging stacks in CentOS. We currently have in CentOS RabbitMQ >> > handling AMQP 0.9, and QPID, which provides messaging using >> > AMQP 1.0. There are also packages supporting Kafka, but not >> > Kafka itself. >> > >> > Collaborating SIGs would be the Cloud and the Opstools SIGs. >> > Both would be consuming built packages produced by the Messaging SIG. >> > >> > We also briefly took into consideration to incorporate the newly >> > proposed SIG into one of the others. At the end, messaging is >> > different than Cloud or Operational tools. It doesn't really fit. >> > The best solution seemed to us to have another SIG. >> > >> > If there are any questions or comments, please don't hesitate >> > to reply to the list, and let's find the best proposal here. >> > >> > Matthias >> >> Both rabbitmq and qpid packages already exist in EPEL. RabbitMQ is on >> the latest 3.6.x version but that is dependent on the version of erlang >> that's available - and EPEL currently supplies R16B-03.18.el7. The 3.6 >> series is still current and supported AFAIK. Getting a more recent >> version would mean a rebase of erlang. >> >> Don't know anything about qpid but the EPEL packages are currently >> 1.38.0-1.el7 > > So, EPEL is not acceptable in Opstools nor in Cloud. If you want to link > against libraries, you'll need to have them available directly in the > build system, not via external repositories. > > The other thing I really like with the idea of having a SIG is its > clear (and small) focus. With that, you don't need to worry that some > other package gets overwritten. > > 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. So EPEL seems to have 2 different sets of problems occurring. We get told by SIG A that the version of package is too old for them and it needs to be updated. It then gets updated and it breaks SIG B. And shortly later something SIG-B needs is going to break SIG-A. There is also the problem that the users can't mix and match Sig-A and Sig-B which was the original impetus several of those things being in EPEL. I am looking for ideas on how to better serve both problems but there is a point where it is each SIG needs to either work with each other or make sure that are clear what they can't mix with. -- Stephen J Smoogen.