+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
