[Development] QtFluentMQ

Wed Aug 30 06:57:09 CEST 2023

Hello,

> +1 in general.

> However, gerrit users should be individual contributors rather than a team
> user that is shared by multiple people, and the responsible person needs to
> have a gerrit user account.

> So, if nobody objects within a few days, please create a QTQAINFRA task
> in JIRA with the necessary details, including the gerrit user for George Ransdall.
> Other contributors from the QtFluentMQ team can already create
> Qt Accounts/gerrit users as well, of course.

In that case we'd rather have our software integrator responsible for the guerrit integration of our sprints to simplify the process. He already created a guerrit account and a task under QTQAINFRA with the proper assignees, we'll pass it in an open state if nobody objects in the upcoming days.

We do work using the agile method, the sprints that we'll be using for the playground release plan are described below.

[cid:17b3d247-211b-41f5-8677-2d1822e788a6]
We did not include all the MQ backends in the guerrit playground release plan that we'll be implementing in-house to give the Qt team a manageable code base for the purpose of assessment and CI planning. if that goes well and leads to a module integration plan, we'd provide you with the remaining backends in whatever repository you'd see fit for the module.

Please note that while the guerrit repo deliveries are feature complete and fully testable code freezes, you'll still need to deploy broker images and tooling to your CI servers to test the client. For that we can either provide you with our all-in-one init script under the guerrit playground repo with some documentation as a temporary hack or we can have our integrator coordinate with your CI team to install the environment for you and walk you through the CLI & perf tooling.

Best regards,
QtFluentMQ Team

________________________________
From: Volker Hilsheimer <volker.hilsheimer at qt.io>
Sent: Tuesday, August 29, 2023 12:26 PM
To: Alex Blasche <alexander.blasche at qt.io>
Cc: team fluentmq <fluentmq at outlook.com>; development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] QtFluentMQ

+1 in general.

However, gerrit users should be individual contributors rather than a team user that is shared by multiple people, and the responsible person needs to have a gerrit user account.

So, if nobody objects within a few days, please create a QTQAINFRA task in JIRA with the necessary details, including the gerrit user for George Ransdall. Other contributors from the QtFluentMQ team can already create Qt Accounts/gerrit users as well, of course.

Volker

> On 28 Aug 2023, at 08:57, Alex Blasche <alexander.blasche at qt.io> wrote:
>
> +1 from me as it is the Foundation area which will mostly support the process/development.
>
> --
> Alex
>
>
> ________________________________________
> From: Development <development-bounces at qt-project.org> on behalf of team fluentmq <fluentmq at outlook.com>
> Sent: Sunday, August 27, 2023 03:55
> To: Volker Hilsheimer; development at qt-project.org
> Subject: Re: [Development] QtFluentMQ
>
> Hello,
>
> Thanks for welcoming the project everybody.
>
>> AFAIR we haven't bike shedded over the commercial value of a new repository, the architecture of the code it shall hold, or its licensing before. I don't think we need to.
> To be fair, while we're Qtifying our API to give back to the community as Qt has been good for us for a long time going, we're also looking forward to acheive framework community grade robustness through a Qt integration as this is the most sensitive part of our product designed for (extra) large scale distributions. We did ask for an intent of integration had the project held its ground in term of compatibility with the Qt project for us to allocate the ressources for that which is why Volker mentioned the need for internal discussions. Using the playground as an assessment buffer for the integration sounds like a party !
>
>> You should fill in at least the basic information, though: name and description, responsible person, and desired location.
>
> name: QtFluentMQ
> description:
>
> The "QtFluentMQ" project aims to create a user-friendly and versatile message queue (MQ) client using the Qt 6 framework. This client seamlessly handles communication with major MQ platforms. The first release would implement the AMQP protocol thus supporting RabbitMQ, ActiveMQ, Apollo, Artemis, IBM MQ, Amazon MQ and more. It will also migrate the existing Kafka implementation to Qt to support the Kafka platform as well, the current MQ market leader.
>
> At its core, the project involves a top-layer abstraction called QMQInstance. This layer acts as a bridge between the application and various MQ platforms. Within this layer, there are two main components: QConsumer and QProducer, which can also be referred to as QQmlConsumer and QQmlProducer when working with QML.
>
> QMQInstance provides a unified QMessage Interface that simplifies the process of sending and receiving data to and from different MQ brokers. This uniform interface streamlines the interaction with multiple MQ platforms, making it easier for developers to integrate messaging functionality into their applications.
>
> One of the standout features of this project is its dynamic configurability. The client can be configured through a JSON input. This flexibility allows developers to adapt the client's behavior to specific use cases and requirements without significant code changes.
>
> Additionally, the project supports queues context switching. This means that the client can seamlessly switch between different queues or channels within the MQ platforms. This feature is particularly useful for managing multiple communication channels efficiently and ensuring the smooth flow of data.
>
> Finally, the QtFluentMQ actively supports open-source initiatives like Plumber<https://github.com/streamdal/plumber>, a versatile CLI tool for seamless interaction with various messaging systems, including Kafka and RabbitMQ. By collaborating with projects like Plumber, Fluent MQ enhances the CI/CD process by offering an all-in-one tooling package that streamlines operations and simplifies integration tasks."
>
> In summary, QtFluentMQ project offers a comprehensive and easy-to-use solution for interacting with various MQ platforms. Its abstraction layer, dynamic configurability, and support for queues context switching contribute to a seamless messaging experience for developers working with Qt 6 applications.
>
> responsible person:  George Ransdall<mailto:fluentmq at outlook.com>
>
> desired location: Playground
>
> Br
> QtFluentMQ Team
>
>
> ________________________________
> From: Volker Hilsheimer <volker.hilsheimer at qt.io>
> Sent: Saturday, August 26, 2023 11:34 AM
> To: Ulf Hermann <ulf.hermann at qt.io>; development at qt-project.org <development at qt-project.org>
> Subject: Re: [Development] QtFluentMQ
>
>> On 26 Aug 2023, at 10:09, Ulf Hermann via Development <development at qt-project.org> wrote:
>>
>> Hi,
>>
>> The usual way to request a repository, playground or not, is a mail like this:
>>
>> https://lists.qt-project.org/pipermail/development/2022-August/042900.html
>>
>> If the request is not totally outlandish it's usually granted, possibly after some bike shedding over the name and location.
>>
>> AFAIR we haven't bike shedded over the commercial value of a new repository, the architecture of the code it shall hold, or its licensing before. I don't think we need to.
>>
>> You should fill in at least the basic information, though: name and description, responsible person, and desired location.
>>
>> At least sometimes, we have used the lazy consensus mechanism for repository requests in the past. This seems a good idea to me. I will +1 this one if the (still missing) basics are reasonable.
>>
>> We can still discuss the way to integrate with the rest of Qt once we can see some code.
>
>
> It’s good to understand the ambitions and state of the project when deciding the location of the repo, hence my questions. From what I read about the state in particular, a repository in the playground/ namespace seems to make more sense than starting under qt/ and adding this to the qt5.git super repository immediately, as our wiki page suggests it should.
>
> So if team QtFluentMQ can provide the missing bits of information, then we can just go ahead with this if no-one objects.
>
>
> Cheers,
> Volker

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230830/1221fa71/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-e340qlrh.png
Type: image/png
Size: 68793 bytes
Desc: Outlook-e340qlrh.png
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230830/1221fa71/attachment-0001.png>