[Development] Status of the QtFeedback module

[Aleix Pol]

On Thu, May 6, 2021 at 6:01 AM Chris Adams <chris.adams at qinetic.com.au> wrote:
>
> Hi Aleix,
>
> Comments inline.
>
> On Thu, May 6, 2021 at 12:43 AM Aleix Pol <aleixpol at kde.org> wrote:
>>
>> On Tue, Apr 27, 2021 at 2:28 AM Chris Adams <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> 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).

In general distros are wary of pulling from a random git tag and
prefer having tarballs. Having a qtfeedback (or a
not-really-qt/qtfeedback) subdirectory in here with the tarballs
matching git tags would be enough.
https://download.qt.io/archive/

And then if CI and such can be run like for Qt modules that would be
grand as well. We have no need in QtFeedback being part of binary
releases as we do not use these. Regarding the different platforms, we
need this for Plasma Mobile so it's only necessary on linuxy ones. Of
course in the interest of the module we might want to run it on other
supported platforms. I'm personally not familiar enough with
QtFeedback to assess how far that would go.

Aleix