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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.