[Development] Deprecating modules with 5.5

[Robert Knight]

> ...and you're keeping up to date with all the security patches
> to Qt, Chromium, etc.? If not, your "better experience" is leaving
> your application's users vulnerable.

We have the capability to turn around an update quickly if necessary and
try to use system libraries where possible, especially for things like
networking, but this misses the point. The majority of desktop users, even
technically knowledgeable ones, care first and foremost about having
working tools.

The trade-offs look different if you're talking about a piece of
infrastructure (eg. a web server) and for that domain, distro policies
around bundling make a lot of sense.

On Fri Feb 06 2015 at 18:45:27 Matthew Woehlke <
mw_triad at users.sourceforge.net> wrote:

> On 2015-02-06 09:22, Robert Knight wrote:
> >> It is just not practical to ship a second copy of dozens
> >> of system libraries, all built as part of QtWebEngine. This is a
> nightmare
> >> in terms of disk space, RAM use, potential for symbol conflicts and
> >> delivery of security updates.
> >
> > These are all valid concerns but ultimately of secondary importance to
> most
> > app developers
> > who care most about delivering working software to their end users and
> for
> > them the OS X / Windows
> > model of bundling anything not guaranteed to be part of the base platform
> > works quite nicely.
> >
> > We ship a complete copy of Qt in our non-open source app for Linux and a
> > runtime wrapper that will
> > choose on the fly whether to use it or not. Because of that we are able
> to
> > offer a _better_ experience
> > for our users than packaged open source software, which sucks.
>
> ...and you're keeping up to date with all the security patches to Qt,
> Chromium, etc.? If not, your "better experience" is leaving your
> application's users vulnerable.
>
> Bad enough for individual applications to shoulder that burden. When you
> talk about the cost of maintaining a web engine, don't forget that by
> bundling Chromium, *you* (i.e. the Qt project) are taking on
> responsibility for the security of that entire stack. This means
> releasing a new version *of Qt* whenever a security issue is found in
> Chromium. Or in anything that Chromium bundles.
>
> Putting myself in the library/framework developer role, I would strongly
> want to punt that burden to upstream / the distro.
>
> --
> Matthew
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150208/1c7aff74/attachment.html>