[CentOS-devel] [RFC] New SIG Messaging

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.