+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.blas...@qt.io> wrote:
> 
> +1 from me as it is the Foundation area which will mostly support the 
> process/development.
> 
> --
> Alex
> 
> 
> ________________________________________
> From: Development <development-boun...@qt-project.org> on behalf of team 
> fluentmq <fluen...@outlook.com>
> Sent: Sunday, August 27, 2023 03:55
> To: Volker Hilsheimer; development@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:fluen...@outlook.com>
> 
> desired location: Playground
> 
> Br
> QtFluentMQ Team
> 
> 
> ________________________________
> From: Volker Hilsheimer <volker.hilshei...@qt.io>
> Sent: Saturday, August 26, 2023 11:34 AM
> To: Ulf Hermann <ulf.herm...@qt.io>; development@qt-project.org 
> <development@qt-project.org>
> Subject: Re: [Development] QtFluentMQ
> 
>> On 26 Aug 2023, at 10:09, Ulf Hermann via Development 
>> <development@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


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to