Hi,

There are many add-ons that work perfectly well on mobile. Essentials should be 
such that are as the name suggest essential for the Qt based applications (or 
devices). Furthermore, the essentials need to work on all platforms. This means 
also the embedded and RTOS platforms, not only desktop and mobile.

Yours,

        Tuukka 

On 22.5.2020, 17.20, "Development on behalf of Jason H" 
<development-boun...@qt-project.org on behalf of jh...@gmx.com> wrote:

    Will this have repercussions in the Maintenance tool?
    I don't really think that calling Multimedia an "add on" is a reflection of 
reality, post 1994.
    For mobile kits (iOS, Android) these are essential features. Sorry, Qt just 
can't get away with drawing rectangles and text in 2020. I fear this is more 
maligning of mobile by Lars. I think this will result in providing a lower tier 
of service than compared to the "essentials".

    I object, and wish multimedia to remain an essential part of Qt. 





    > Sent: Friday, May 22, 2020 at 3:47 AM
    > From: "Lars Knoll" <lars.kn...@qt.io>
    > To: "Giuseppe D'Angelo" <giuseppe.dang...@kdab.com>
    > Cc: "Qt development mailing list" <development@qt-project.org>
    > Subject: Re: [Development] Qt Multimedia as Add-on in Qt 6
    >
    > Hi,
    > 
    > > On 21 May 2020, at 18:08, Giuseppe D'Angelo via Development 
<development@qt-project.org> wrote:
    > > 
    > > Hi,
    > > 
    > > Il 21/05/20 11:38, Val Doroshchuk ha scritto:
    > >> The license is not changed, plans just to not ship QtMultimedia with 
Qt essentials,
    > >> can be installed separately. Possibly we also support only a limited 
set of platforms.
    > >> Qt Essentials must work on every platform, according to the definition 
of essentials.
    > > 
    > > While of course it's up to each module maintainer to decide on its 
status (and thus, if QtMM doesn't qualify for "Essentials" any more, can become 
an "Addon"), I'm left wondering why does this imply being moved to the 
Marketplace, out of Qt itself?
    > > 
    > > 
    > > * Is this part of a broader plan, aiming at streamlining the Qt offer 
to just mean Essentials, while the Addons get moved to the marketplace?
    > 
    > This is something I’ve been at least mentioning at the Contributor Summit 
already. Distributing it through the market place is mainly a different means 
of packaging it and decoupling the release schedules. A user should still be 
able to discover and install Qt MM (or other add-ons delivered through the 
market place) in the installer, just as today.
    > 
    > But yes, this goes then towards streamlining Qt 6 a bit. Reducing the set 
of things that you have to install, and making more modules optional.
    > > 
    > > ("Qt offer" is of course inaccurate, given the many offers available, 
but you get my drift...).
    > > 
    > > 
    > > * If so, are all the practical issues for such addons sorted out? First 
few things that come to mind:
    > > 
    > > 1) Version numbering scheme, release schedule
    > 
    > This needs some sorting out, I agree.
    > 
    > > 2) CI testing / platform coverage
    > 
    > That should be ok for now, although if an add-on targets several Qt 
versions at once, we don’t yet have a good mechanism to deal with that in CI.
    > 
    > > 3) Compatibility promise (own API/ABI stability, which Qt versions it 
works with, etc.)
    > 
    > I think it will be good to give add-ons a bit more flexibility there how 
to handle it. This is because different add-ons have rather different 
requirements, that we’ve so long all tried to shoehorn into the Qt release 
process. Compare for example WebEngine that needs frequent updates due to new 
Chromium releases with e.g. Qt SVG that only receives a very limited amount of 
bug fixes.
    > 
    > > 4) Where to put the docs, release notes, etc.
    > 
    > Into the package and on the web site as usual.
    > > 
    > > 
    > > * What about the KDE/Qt agreement? Are the list of Essential and Addon 
modules being re-evaluated there as well? QtMM is not really at liberty of 
changing license because it's an "Essential" (in the agreement).
    > 
    > There’s the agreements legal term, and the status in terms of the 
agreement is something we can’t change without agreement from the board of the 
KDE Free Qt Foundation.
    > 
    > When the new agreement was done some years ago, we tried to align terms 
with what we had in Qt Project at that time. But things do change and I believe 
we can change what we see as essential and add-on in terms of the project (and 
in the commercial packages) independently of the agreement. 
    > 
    > This is confusing to some extent as the legal agreement uses the same 
terms as we’re using, but the terms are defined in the agreement itself, and 
limited to the scope of the agreement. They don’t dictate how we package or 
name things in our releases (as long as the conditions set forth in the 
agreement are fulfilled).
    > 
    > The main thing the agreement mandates is the licensing of add-on and 
essential modules. But the only real difference between add-ons and essentials 
(as defined in the agreement) are that essentials have to be LGPLv3, while 
*new* add-ons can be GPLv3. We can’t change licensing of currently supported 
modules without agreement from the foundation in neither case. We also can’t 
reduce the scope of the agreement, so Qt Multimedia will be part of that 
agreement no matter how we package and deliver it to our users.
    > 
    > Cheers,
    > Lars
    > 
    > _______________________________________________
    > Development mailing list
    > Development@qt-project.org
    > https://lists.qt-project.org/listinfo/development
    >
    _______________________________________________
    Development mailing list
    Development@qt-project.org
    https://lists.qt-project.org/listinfo/development

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

Reply via email to