[CentOS-devel] [RFC] New SIG Messaging

[Stephen John Smoogen]

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.