On 2 July 2018 at 13:54, Neal Gompa <ngompa13 at gmail.com> wrote: > 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? > 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. > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel -- Stephen J Smoogen.