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 <[email protected]> on behalf of Chris Adams
<[email protected]>
Date: Thursday, 6. May 2021 at 7.06
To: Aleix Pol <[email protected]>
Cc: Qt Development List <[email protected]>
Subject: Re: [Development] Status of the QtFeedback module
Hi Aleix,
Comments inline.
On Thu, May 6, 2021 at 12:43 AM Aleix Pol
<[email protected]<mailto:[email protected]>> wrote:
On Tue, Apr 27, 2021 at 2:28 AM Chris Adams
<[email protected]<mailto:[email protected]>> 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
> <[email protected]<mailto:[email protected]>> 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
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
