On Mon, Jul 2, 2018 at 11:14 AM 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. > 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? 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. -- 真実はいつも一つ！/ Always, there's only one truth!