From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 3/3] qt5quick1, qt5script, qt5webkit: tag as deprecated
Date: Fri, 3 Jul 2015 09:43:04 +0200 [thread overview]
Message-ID: <20150703094304.663cee42@free-electrons.com> (raw)
In-Reply-To: <4fef60e5-fbfb-4595-8c48-646c3d00a3d0@MAIL-SINTERS-01.sinters-int.fr>
Julien,
On Fri, 3 Jul 2015 07:20:54 +0000, Julien CORJON wrote:
> diff --git a/package/qt5/Config.in b/package/qt5/Config.in
> index e8ec7d9..49e3450 100644
> --- a/package/qt5/Config.in
> +++ b/package/qt5/Config.in
> @@ -36,15 +36,16 @@ source "package/qt5/qt5enginio/Config.in"
> source "package/qt5/qt5graphicaleffects/Config.in"
> source "package/qt5/qt5imageformats/Config.in"
> source "package/qt5/qt5multimedia/Config.in"
> -source "package/qt5/qt5quick1/Config.in"
> source "package/qt5/qt5quickcontrols/Config.in"
> -source "package/qt5/qt5script/Config.in"
> source "package/qt5/qt5sensors/Config.in"
> source "package/qt5/qt5serialport/Config.in"
> source "package/qt5/qt5svg/Config.in"
> -source "package/qt5/qt5webkit/Config.in"
> -source "package/qt5/qt5webkit-examples/Config.in"
> source "package/qt5/qt5websockets/Config.in"
> source "package/qt5/qt5x11extras/Config.in"
> source "package/qt5/qt5xmlpatterns/Config.in"
> +comment "Depracated Qt modules"
Deprecated
but I don't think it's really worth to have them in a separate part of
the menu, since all of them already have a "(deprecated)" indication in
their prompt.
However, I'm wondering if we should not simply make them depend on
BR2_DEPRECATED_SINCE_2015_08. But that will make them disappear
completely by default, unless the user enables BR2_DEPRECATED.
Actually, our deprecation/removal process is a bit weird: deprecated
should be a smoother thing than removal. But in practice, when we
deprecate something by making it 'depends on
BR2_DEPRECATED_SINCE_YYYY_MM', it gets automatically removed from your
configuration without any notification (unless you enable manually
BR2_DEPRECATED, of course). While if we remove it entirely, we add it
to Config.in.legacy, and the users upgrading get a clear notification.
So users are better notified of removals than deprecations.
Arnout, what do you think about this?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-07-03 7:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1435908049-11930-1-git-send-email-corjon.j@ecagroup.com>
2015-07-03 7:20 ` [Buildroot] [PATCH 2/3] qt5base: reorder patches Julien CORJON
2015-07-03 7:20 ` [Buildroot] [PATCH 3/3] qt5quick1, qt5script, qt5webkit: tag as deprecated Julien CORJON
2015-07-03 7:43 ` Thomas Petazzoni [this message]
2015-07-03 8:55 ` Julien CORJON
2015-07-03 16:47 ` Arnout Vandecappelle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150703094304.663cee42@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox