[Development] Status of the QtFeedback module

[Tuukka Turunen]

Hi,

We can increase the test coverage (e.g. additional CI configurations) and if needed it is possible to have the playground and other modules to be packaged into a ‘release’ source package. Typically users are simply pulling from the repos directly, though.

If the module is not tightly coupled to other modules and mostly using the public API it is not prone to break easily with new releases of Qt rolling out. The main item of concern is the level of maintenance being clear to the users. For this reason we are a bit conservative in adding the new libraries to binaries. Longer term the goal is to make this more versatile with a package manager solution.

Yours,

                Tuukka

From: Development <development-bounces at qt-project.org> on behalf of Chris Adams <chris.adams at qinetic.com.au>
Date: Thursday, 6. May 2021 at 7.06
To: Aleix Pol <aleixpol at kde.org>
Cc: Qt Development List <development at qt-project.org>
Subject: Re: [Development] Status of the QtFeedback module
Hi Aleix,

Comments inline.

On Thu, May 6, 2021 at 12:43 AM Aleix Pol <aleixpol at kde.org<mailto:aleixpol at kde.org>> wrote:
On Tue, Apr 27, 2021 at 2:28 AM Chris Adams <chris.adams at qinetic.com.au<mailto:chris.adams at qinetic.com.au>> wrote:
>
> Hi Jonah,
>
> I'm not part of the Qt Company, so please consider my comments as discussion only ;-)
>
> I'm the maintainer of the QtFeedback module, at least insofar as I am willing to review commits and keep things building.  Sailfish OS uses this module, which is why I am still interested in keeping it working etc.  Specifically in the case of QtFeedback, there has been no active development on it for a long time, as you mention, although no doubt many improvements would be possible given that we probably need not maintain BC/SC at this point...  Given that the rate of change in the repository is so slow, why is packaging from git snapshot difficult in this case?  And what sort of development do you see likely to occur, should it move under the KDE umbrella instead (and, out of curiosity, why could that development not occur under the Qt project?)
>
> Best regards,
> Chris.
>
>
> On Sat, Apr 24, 2021 at 7:12 AM Jonah Brüchert <jbb at kaidan.im<mailto:jbb at kaidan.im>> wrote:
>>
>> Hi,
>>
>> I'm one of the people working on the Plasma Mobile project. We are using
>> the QtFeedback module, and it would be very useful for us to have a
>> release of the module, as packaging git snapshots is making life harder
>> than necessary for packagers. I'm aware the module is currently not
>> actively developed, but it is commonly used in other mobile user
>> interfaces. Are there any plans for it?
>>
>> If the Qt project is no longer interested in the module, we would
>> consider developing it under the KDE umbrella. If you are also using the
>> module, I'd be interested in which backend you are using, so we don't

(Oops, I guess I forgot to respond to this from the original email:
https://git.sailfishos.org/mer-core/qt-mobility-haptics-ffmemless)

>> end up with multiple forks but ideally something like a KDE tier 1
>> framework that anyone can use just like right now.
>>
>> Thanks,
>>
>> Jonah

I guess the biggest problem here is that the Qt project is not
releasing this component, so we're in a weird position when it comes
to developing it further.

Do you mean binary release, or just some version bump and tag?
Would you expect e.g. BC/SC guarantees (I assume so)?
Would you want the major version to be that of Qt (e.g. 6) or separate?

What is required (from Qt Project) to make releases of such a module?
(I guess it's an add-on module, or perhaps even considered a labs module.)
Is it possible for someone not employed by The Qt Company
(e.g. me, for example) to do whatever is required to make releases for
this module (e.g. just by tagging things appropriately to trigger CI machinery),
or is it something which requires internal access?

If it moved to KDE, we could issue releases. If Qt project decides
that it's an interesting module and decides to release it, then that
could work as well.

I wonder if someone from The Qt Company (maybe Alex Blasche?) would
have some thoughts here?  E.g. depending on what is required to make
releases, it could be something which requires either very little work from
The Qt Company, or it could be something which requires substantial work...

>From my (admittedly biased) perspective, it seems like this is something
that does have value for the Qt community, since there are obviously at
least two prominent projects which are relying on this Qt module currently.
So, from that point of view, it would be nice if the Qt Project could make
releases, if that is the primary stumbling block for existing users and
contributors such as Plasma Mobile.

We just need to get it out of this odd freeze in time it's in right now.

Yep, I agree.  Thanks to Jonah and yourself for raising it, hopefully we
can at least define a concrete plan to move forward (either within the
Qt Project or within KDE if that proves to be the pragmatic option).

Best regards,
Chris.


Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20210506/74674290/attachment.html>